users@grizzly.java.net

Re: Comet - weird memory behaviour

From: Daniel Lopez <greeneyed_at_dev.java.net>
Date: Tue, 28 Apr 2009 19:42:28 +0200

As an added bonus, sorry if it already is implemented like that as I
had no time to look at the source, one could implement the cache using
Weak References, so it does not contribute to an OOM under any
circumstance.

S!
D.

2009/4/28 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>:
> 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
>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>