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?
>
> 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
>