Salut,
Jacob Kessler wrote:
> 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.
OK, but this is not a Grizzly issue :-). Grizzly cannot by default get
rid of Adapter for trivial performance reason (sync on ProcessorTask
instance). The solution for you is to extend the HttpWorkerThread and
clear its field (In you case the ProcessorTask) when you detect and
undeploy. So you need to write your own ThreadPool which extend the one
under the http module. I can help Thursday (holiday here now).
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
>