Jeanfrancois Arcand wrote:
> [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
From what I see in my code and the unregister API, I am calling
unregister with the correct value.
> (2) The V3Mapper doesn't remove properly the context-root and it's
> associated object.
I suspect this as well. I will fire-up the debugger and see whats going
on inside unregister.
-vivek.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>