Jeanfrancois Arcand wrote:
>
>
> Vivek Pandey wrote:
>> I have reported an issue:
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8617
>>
>
> Thanks. If you can get a profiler output that show that the JRubyAdapter
> gets referenced by the grizly-kernel code, that will help :-)
Thanks for the profiler data. As I explained in the issue, the bug
happens because the MappingData used in v3 keep a reference to the
JRubyAdapter. The fix will consist of recycling this specific object to
make sure the Adapter is not getting referenced. I will implement it
inside the GlassFish v3 ContainerMapper's service method.
Thanks!
-- Jeanfrancois
>
> Thanks!
>
> -- Jeanfrancois
>
>
>> -vivek.
>> Vivek Pandey wrote:
>>>
>>>> Just curious, event if you nullify all the reference it is still
>>>> causing a leak?
>>> The whole container is set to null. I think setting to null just
>>> means it is marked for GC but if there are references to resources
>>> from somewhere else it would not get GCed.
>>>
>>> I just replied to your latter mail. It looks like going thru
>>> WorkerThread is non-trivial or I am not sure how the synchronization
>>> would happen correctly and thee performance implication of it.
>>>
>>> -vivek
>>>> I'm asking because the solution is far from trivial to implement
>>>> for v3.
>>>>
>>>
>>>
>>>>
>>>>>> so the instance is not causing a leak. That way we will be able to
>>>>>> re-use that instance
>>>>>
>>>>> instance of JRubyGrizzlyAdapter? We don't want that.
>>>>> JRubyGrizzlyAdapter is per application. It's lifecycle should end
>>>>> with the application. It is not shared across other apps.
>>>>>> for the next request instead of freeing the WorkerThread. If you
>>>>>> still think the WorkerThread needs to be free (we only have 5
>>>>>> threads per default), why not clearing it inside the destroy()?
>>>>>>
>>>>>> https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/tcp/http11/GrizzlyAdapter.html#destroy()
>>>>>>
>>>>>>
>>>>>> Would that work?
>>>>>>
>>>>> When/who calls GrizzlyAdapter.destroy()? I see it is implemented in
>>>>> GrizzlyAdapterChain():
>>>>>
>>>>> public void destroy() {
>>>>> for (Entry<GrizzlyAdapter, String[]> adapter :
>>>>> adapters.entrySet()) {
>>>>> adapter.getKey().destroy();
>>>>> }
>>>>> }
>>>>
>>>> Right but that class is not used in v3. The burden of the work will
>>>> need to happens inside the ContainerMapper class.
>>>>
>>>>>
>>>>> How do I know which WorkerThread has reference to
>>>>> JRubyGrizzlyAdapter and how do I get the current WorkerThread, so
>>>>> that I could call WorkerThread.reset()?
>>>>
>>>> There is no such thing implemented right now in v3 (and Grizzly). So
>>>> what needs to be done is:
>>>>
>>>> (1) Store all references of created WorkerThread.
>>>> (2) As soon as you undeploy your application, cycle over all the
>>>> WorkerThread, detect if the Adapter is the one undeployed, then free
>>>> it.
>>>>
>>>> Note that Adapter are set on the fly, so we gonna need some synchro
>>>> to make sure we aren't freeing a Thread and at the same time the
>>>> ContainerMapper is about to set it. So this is clearly a
>>>> costly/dangerous solution IMO. But if that's the only one :-)
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>>
>>>>> -vivek.
>>>>>
>>>>>
>>>>>> A+
>>>>>>
>>>>>> -- Jeanfrancois
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> -vivek.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>