Jeanfrancois Arcand wrote:
>>
>> 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
There is only one Adapter (which is good), and the state that it holds
onto is an instance of the JRuby interpreter (which otherwise takes 5+
seconds to load). We want that JRuby interpreter to persist across all
requests served by the adapter (as it does), but want to be able to
clear the worker thread caches on application undeploy (when the Adapter
is no longer in use) to free up the memory (particularly permgen) that
the JRuby interpreter uses.