You can reproduce the issue with this test case:
public void testDisposeUnused() throws Exception {
final DefaultMemoryManager mm = new DefaultMemoryManager(
new MyMemoryMonitoringProbe());
Runnable r = new Runnable() {
@Override
public void run() {
// Initialize memory manager
mm.allocate(0);
final int initialSize = mm.getReadyThreadBufferSize();
BuffersBuffer compositeBuffer = BuffersBuffer.create(mm);
for (int i = 0; i < 11; i++) {
Buffer b = mm.allocate(1228);
compositeBuffer.append(b);
}
compositeBuffer.toByteBuffer(0, 12280);
compositeBuffer.position(12280);
compositeBuffer.disposeUnused();
assertEquals(initialSize,
mm.getReadyThreadBufferSize());
}
};
testInWorkerThread(r);
}
Thanks!
Bo
On Mar 23, 2010, at 5:36 AM, Oleksiy Stashok wrote:
> Hi Bo,
>
> I've added DefaultMemoryManagerTest.testDisposeUnused() test to reproduce your problem. It works fine for me.
> Can you pls. take a look at it and modify it, so we'll be able to reproduce the issue?
>
> Thanks.
>
> WBR,
> Alexey.
>
> On Mar 23, 2010, at 1:56 , Bo Li wrote:
>
>> I noticed after introducing disposeUnsed, SSL connections no longer works. I tracked the first one down to the getBufferIndex method in BuffersBuffer:
>>
>> Index: modules/grizzly/src/main/java/com/sun/grizzly/memory/BuffersBuffer.java
>> ===================================================================
>> --- modules/grizzly/src/main/java/com/sun/grizzly/memory/BuffersBuffer.java (revision 4345)
>> +++ modules/grizzly/src/main/java/com/sun/grizzly/memory/BuffersBuffer.java Mon Mar 22 16:58:06 CDT 2010
>> @@ -1281,7 +1281,7 @@
>> return makeLocation(i, buffer.position() + steps);
>> }
>>
>> - steps -= buffer.remaining();
>> + steps -= buffer.limit();
>> }
>>
>> if (steps == 0) {
>>
>>
>> However, now I'm getting the following exception:
>>
>> WARNING: Exception during FilterChain execution
>> java.lang.IndexOutOfBoundsException: Limit 17192 is out of bounds
>> at com.sun.grizzly.memory.BuffersBuffer.locateBufferLimit(BuffersBuffer.java:1339)
>> at com.sun.grizzly.memory.BuffersBuffer.disposeUnused(BuffersBuffer.java:386)
>> at com.sun.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:312)
>> at com.sun.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:225)
>> at com.sun.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:178)
>> at com.sun.grizzly.ProcessorExecutor.resume(ProcessorExecutor.java:73)
>> at com.sun.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:61)
>> at com.sun.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:634)
>> at com.sun.grizzly.strategies.WorkerThreadStrategy$1.run(WorkerThreadStrategy.java:116)
>> at com.sun.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:417)
>> at com.sun.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:398)
>> at java.lang.Thread.run(Thread.java:637)
>>
>> I tried to figure out what locateBufferLimit does but it doesn't seem clear. My BuffersBuffer is composed of 13 Buffers of whose limit = 1228, pos = 1228, cap = 1228. The last buffer has a limit = 1228, pos = 0, cap = 1228.
>>
>> Is this a bug with locateBufferLimit or something else?
>>
>> Thanks
>> Bo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>