dev@glassfish.java.net

Re: SelectorThread and recycling problem

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

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