dev@glassfish.java.net

Re: SelectorThread and recycling problem

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 20 Jan 2009 11:21:30 +0100

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