users@grizzly.java.net

Re: Comet - weird memory behaviour

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 28 Apr 2009 11:32:08 -0400

Salut,

FredrikJ wrote:
>
> Jeanfrancois Arcand-2 wrote:
>>
>>> Are there any snapshot releases in any repository I can try and update
>>> to?
>> Yes. Just download Grizzly 1.0.27 from here:
>>
>> https://maven-repository.dev.java.net/repository/grizzly/jars/
>>
>> and add this jar to your classpath-prefix in domain.xml
>>
>> or download 2.2 nightly:
>>
>> http://javaweb.sfbay/java/re/glassfish/9.1.1/nightly/bundles/latest
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>
> I have patched to the Grizzly 1.0.27.jar (the 2.2 link was down) in my
> Glassfish. Memory is subjectively better in terms of churn and long term
> memory leakage (I need to verify this), but I was still seeing the direct
> increase in memory which would not be released (ever).
>
> Anyway, I poked around in the source code and I think that what's happening
> is that the cache/pools asyncProcessors and interrruptedQueue in
> DefaultAsyncHandler grows aggressively due to many concurrent requests to
> the system. Since we have a delay in the request, the concurrent tasks in
> the system will increase as well.
>
> The caches are never cleaned up, so they will be permanently sized after the
> historical 'peak usage'. In my scenario above we got about 400 tasks in the
> caches after 500 requests which made it seem like something went awry.
>
> However, even though I think it is nicer to release resources when possible
> (i.e when things calm down), I do not think this will cause any long term
> leakage or degradation...
>
> Does this sound plausible?

Yes, but based on your feedback I think I will go ahead and limit the
size of the pool so it doesn't grow forever under load. It will not hurt
to have an upper bound IMO. I will release 1.0.28 with the fix.

Thanks!

-- Jeanfrancois

>
>
>
>
>
>