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?
--
View this message in context: http://www.nabble.com/Comet---weird-memory-behaviour-tp23257612p23279395.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.