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