dev@grizzly.java.net

Re: WorkerThread caches not clearing correctly?

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 30 Jun 2009 12:12:27 -0400

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!

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