Jeanfrancois Arcand wrote:
> Salut,
>
> Jacob Kessler wrote:
>> While trying to diagnose a permgen leak in the JRuby support for
>> GlassFish, we noticed that WorkerThreads cache their most
>> recently-served Request object in their thread local, and don't seem
>> to let it go until they serve another request. For us, that means
>> holding on to the JRuby classloader and all 20MB of permgen that that
>> represents through undeploy/redeploy cycles, which we'd rather didn't
>> happen.
>
> Hum...we recycle the Request object so everything should go away. What
> exactly stay in the Request object? Attributes?
The Request does get recycled when the worker thread serves a new
request, that's not the issue.
The issue is that until that worker thread serves a new request, the
context of the request holds a copy of the
com.sun.grizzly.jrubyRackGrizzlyAdapter that served the request, which
in turn needs to be holding objects that prevent the JRuby classloader
from being garbage collected after the application that it was serving
is undeployed, which means that in development environments (where
requests served to redeployments approach 1:1) permgen usage climbs
unreasonably. What I'm wondering is whether the Request should be
cleared on application undeploy, and (if it shouldn't, for whatever
reason) if there is a way to force it to clear to prevent the
inappropriate caching that we are seeing.
>
>
>>
>> Is this correct/desired behavior?
>
> Yes, this is the correct behavior. We cache the ProcessorTask on a
> Thread.
>
>
> If so, is there a good way to get
>> Grizzly to flush the caches without sending through a bunch of
>> lightweight requests to flush the classloaders out, preferably
>> something we can call from within our module on undeploy? If not, I
>> assume I should file a bug for it?
>
> Well I think this is a JRuby/implementation issue. The
> Request/Response object should be cleared (inside the Adapter).
>
> Does it makes sense?
>
> A+
>
> -- Jeanfrancois
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>