[cut]
>>>
>>> The GrizzlyAdapter has a method call destroy(). I would think the
>>> JRubyGrizzlyAdapter should clean up it's resource from there,
>> We are already cleaning up the resources on undeploy. But the fact
>> that JRubyGrizzlyAdapter still has references to these resources so
>> till JRubyGrizzlyAdapter is unreferenced we cant get everything gced
>> overtime.
>
> Just curious, event if you nullify all the reference it is still causing
> a leak? 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 :-)
Actually looking at the code, the WorkerThread doesn't have any
reference to the JRubyAdapter. In v3, the only Adapter tie to the
WorkerThread is the ContainerMapper, which in turn bind the context path
to the Adapter. So if JRubyAdapter are reachable, that's because:
(1) the unregister is not called with the proper value
(2) The V3Mapper doesn't remove properly the context-root and it's
associated object.
I suspect (2) is the issue.
A+
-- Jeanfrancois
>
> 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
>