I think the heap analysis tool misslead me....
The admin console's selector thread contains by default a cache of processor
task that has not been used, so its collection of processor task is not
empty and appear to be the bigest objet of the heap. Each
DefaultProcessorTask reference a the same selector thread
By using OQL query, I find out that only the comet's selector thread has an
empty collection of processorTask but a collection of readTask that contains
6000 elements.
Processor Task are kept in an object called DefaultAsyncHandler. For some of
this processors it seems that the buffer has not been flushed and
DefaultProcessorTask keep a reference to the buffer that is not empty which
keep the memory very high => buffer has not been flushed, the content
remains in memory.
It is very difficult to give you a test case the code is complex and it
happens on high load. We had a lot of error at the end of our test and when
we have too many exception during write operation in the socket.
If an error occur during a write, then we close the connection by calling
cometContext().resumeCometHandler(this), mybe it is the cause of the
problem.
Are we allowed to call resumeCometHandler method ?
How is it possible that buffer has not been flushed ?
Will the buffer be flush when the task will be reused ?
Thanks
William
--
View this message in context: http://grizzly.1045725.n5.nabble.com/Grizzly-slowly-leaking-with-comet-support-on-version-1-0-39-tp4295847p4298983.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.