I have reported an issue:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=8617
-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
>