users@grizzly.java.net

Re: Grizzly slowly leaking with comet support on version 1.0.39

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Thu, 30 Jun 2011 12:03:44 +0200

Hi William,

can i ask you to file an issue?
Will take a look at this asap.
Just want to make sure, which exactly Glassfish release are you testing
on, is it 3.1 release?

Thanks.

WBR,
Alexey.

On 06/29/2011 11:07 AM, wild wrote:
> Hello,
>
> I made a implementation of comet with all the requirements and memory usage
> is still very high. I am using glassfish 3.1 last edition (so grizzly
> 1.9.x).
>
> A list of processor tasks is growing in SelectorThread class. A jmap confirm
> that and full GC does not clean memory.
>
> When I change an option on the tcp protocol used for comet, then the memory
> goes down (probably because all the threads are destroyed and the memory is
> cleaned up).
>
> So the problem is located on the comet listener which create too much
> Processor Tasks (I think). When I start the server, the memory used is
> around 15Mo, then after a load test of 5800 users with comet streaming the
> memory after the test and a full GC is 750Mo and then after another load
> test with 5800 the memory is 1300Mo.
>
> Even if the processor tasks is not supposed to grow, is there a way to
> delete this cache or clear it ? Is it sure that processor tasks are recycled
> with comet support ?
>
> Thanks.
>
> William.
>
> --
> View this message in context: http://grizzly.1045725.n5.nabble.com/Grizzly-slowly-leaking-with-comet-support-on-version-1-0-39-tp4295847p4534526.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.