Is it possible for you to provide a patch for glassfish 3.1 ?
I think changing a the processorTasks cache to a bounded LinkedBlockingQueue
will be enough. The fact that processorTasks list is filled with a lot of
object means (for me) that all the processor tasks has been released.
Because I use comet, I will have one processor task active per user. So it
grows a lot when I have a lot of user. What I don,t understand is why the
size of queue increase betzeen stress tests. Is it possible that under high
load, the poll method did not return an element event if there are element
in it ?
For me, is the size of the processsor task list is high, I means that all
the connection has been terminated correctly (tell me if I am wrong). Is
there any way to see in jmx the size of this cache ?
Thanks
William.
--
View this message in context: http://grizzly.1045725.n5.nabble.com/Grizzly-slowly-leaking-with-comet-support-on-version-1-0-39-tp4295847p4545326.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.