dev@glassfish.java.net

Re: CoyoteAdapter recycle problem [was SelectorThread and recycling problem]

From: Roman Pokhodzhai <rpohod_at_gmail.com>
Date: Tue, 20 Jan 2009 16:02:11 +0200

Seems to me that *filterChain *in *CoyoteRequest *also should be cleaned
during recycling.

On Tue, Jan 20, 2009 at 2:16 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>wrote:

> posted at https://glassfish.dev.java.net/issues/show_bug.cgi?id=7071
>
> Thank you.
>
>
> Actually request.recycle() and response.recycle() are called in *postProcess
>> *method through *inputBuffer.recycle()*, so request is recycled but *org.apache.coyote.Request.recylce()
>> *doesn't recycle *notesManager* (doesn't clear it). And I'm not sure that
>> simple clearing this property in recycle method will help.
>
>
> Right. I just checked that.
> When CoyoteAdapter works in compatWithTomcat mode - it calls
> CoyoteAdapter.afterService(), which recycles
> internal PwcCoyoteRequest/Response, which are stored as Nodes.
> But when CoyoteAdapter works in default mode - it doesn't clean that nodes,
> which leads to the issues you observe.
>
> I'll forward this issue to web-tier team to check it.
>
> Thank you.
>
> WBR,
> Alexey.
>
>
>>
>> btw, I will post it.
>>
>>
>> On Tue, Jan 20, 2009 at 12:21 PM, Oleksiy Stashok <
>> Oleksiy.Stashok_at_sun.com> wrote:
>>
>>> Hi,
>>>
>>> it looks like bug.
>>> Seems, when DefaultProcessorTask is getting recycled - we don't recycle
>>> Coyote Request and Response:
>>>
>>> @Override
>>> public void recycle(){
>>> if ( taskEvent != null ){
>>> taskEvent.setStatus(TaskEvent.START);
>>> }
>>>
>>> if ( listeners!= null && listeners.size() > 0)
>>> clearTaskListeners();
>>>
>>> socket = null;
>>> dropConnection = false;
>>> key = null;
>>> + request.recycle();
>>> + response.recycle();
>>> }
>>>
>>> Can you pls. file an issue at https://glassfish.dev.java.net/issues?
>>>
>>> Thank you.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>>
>>> On Jan 20, 2009, at 10:38 , Roman Pokhodzhai wrote:
>>>
>>> Hi,
>>>>
>>>> 1) "Hum..I'm not sure the application itself is referenced here. Can
>>>> you elaborate a little?"
>>>> Our application is referenced through
>>>> com.sun.enterprise.loader.EJBClassLoader_at_0xefde040. This is exactly
>>>> the class loader that has loaded our application.
>>>>
>>>> 2) "Yes, the notes are used to avoid object creation. As an example,
>>>> we are putting CoyoteRequest/Response in the note we don't have to
>>>> re-create those object"
>>>>
>>>> Cool, but notes are not recycled anyway. And CoyoteRequest (you can
>>>> find it in trace)(com.sun.enterprise.
>>>> web.connector.coyote.PwcCoyoteRequest_at_0x10cda420)
>>>> keeps a reference chain to our EJBClassLoader even after the
>>>> application itself is undeployed. And this class loader keeps all our
>>>> application classes in PermGen memory
>>>>
>>>>
>>>>
>>>> On 1/19/09, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
>>>>
>>>>> Salut,
>>>>>
>>>>> Roman Pokhodzhai wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> If you use tasks recycling for
>>>>>> com.sun.enterprise.web.connector.grizzly.SelectorThread in your
>>>>>> application (it is used by default) then you get the following
>>>>>> reference chain that keeps the application class loader after the
>>>>>> application is undeployed:
>>>>>>
>>>>>
>>>>> Hum..I'm not sure the application itself is referenced here. Can you
>>>>> elaborate a little?
>>>>>
>>>>>
>>>>>> --> com.sun.enterprise.web.connector.grizzly.SelectorThread_at_0xe0a64e0
>>>>>> (433 bytes) (field processorTasks:)
>>>>>> --> java.util.concurrent.ConcurrentLinkedQueue_at_0xe0ba468 (16 bytes)
>>>>>> (field head:)
>>>>>> --> java.util.concurrent.ConcurrentLinkedQueue$Node_at_0xe0caa80 (16
>>>>>> bytes) (field next:)
>>>>>> --> java.util.concurrent.ConcurrentLinkedQueue$Node_at_0x116288d0 (16
>>>>>> bytes) (field item:)
>>>>>> -->
>>>>>> com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask
>>>>>> @0xe0f6180
>>>>>> (169 bytes) (field request:)
>>>>>> --> org.apache.coyote.Request_at_0xe10bef0 (153 bytes) (field
>>>>>> notesManager:)
>>>>>> --> org.apache.coyote.NotesManagerImpl_at_0xe16b140 (12 bytes) (field
>>>>>> notes:)
>>>>>> --> [Ljava.lang.Object;@0xe1c6e90 (136 bytes) (Element 1 of
>>>>>> [Ljava.lang.Object;@0xe1c6e90:)
>>>>>> --> com.sun.enterprise.web.connector.coyote.PwcCoyoteRequest
>>>>>> @0x10cda420
>>>>>> (190 bytes) (field filterChain:)
>>>>>> --> org.apache.catalina.core.ApplicationFilterChain_at_0x10ce8d48 (28
>>>>>> bytes) (field filters:)
>>>>>> --> [Lorg.apache.catalina.core.ApplicationFilterConfig;@0x10ce8d68(48
>>>>>> bytes) (Element 0 of
>>>>>> [Lorg.apache.catalina.core.ApplicationFilterConfig;@0x10ce8d68:)
>>>>>> --> org.apache.catalina.core.ApplicationFilterConfig_at_0x10e2de48 (20
>>>>>> bytes) (field context:)
>>>>>> --> com.sun.enterprise.web.WebModule_at_0xf3b73b8 (501 bytes) (field
>>>>>> parentClassLoader:)
>>>>>> --> com.sun.enterprise.loader.EJBClassLoader_at_0xefde040 (88 bytes)
>>>>>>
>>>>>> This trace shows that Request objects are not fully recycled. Their
>>>>>> 'notes' are not recycled.
>>>>>> You can also see it at org.apache.coyote.Request.recycle.
>>>>>>
>>>>>>
>>>>>> It there some idea behind it?
>>>>>>
>>>>>
>>>>> Yes, the notes are used to avoid object creation. As an example, we are
>>>>> putting CoyoteRequest/Response in the note we don't have to re-create
>>>>> those object.
>>>>>
>>>>>
>>>>> Or it's just a bug?
>>>>>
>>>>> No. Tomcat does this as well.
>>>>>
>>>>> A+
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>
>
>