Salut,
Jacob Kessler wrote:
> 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.
Hum...The Adapter is stateless by default, only one instance gets
created. We can probably (for JRuby) switch to a new Thread Pool that
clean the HttpWorkerThread's adpater instance....but since this is a
single instance, I don't think that will fix the issue. What you need is
to create a new Adapter per request...but that will kill performance IMO.
Why not clearing the JRubyAdapter state inside its service method?
A+
-- Jeanfrancois
>>
>>
>>>
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>