[ http://issues.apache.org/jira/browse/GERONIMO-1125?page=all ]

Kevan Miller updated GERONIMO-1125:
-----------------------------------

    Geronimo Info: [Patch Available]
      Description: 

After a deploy/undeploy of DayTrader, the following chain of references (there 
are others which I'm investigating) is keeping a MultiClassLoader instance from 
being marked as available for GC.

java.util.TaskQueue.queue --> java.util.TimerTask[128]
    java.util.TimerTask[5] --> 
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser
      IdleReleaser.this$0 --> 
org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor 
        SinglePoolConnectionInterceptor.next --> 
org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor
          XAResourceInsertionInterceptor.next --> 
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor
            MCFConnectionInterceptor.stack --> 
org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor
              ConnectionTrackingInterceptor.next --> 
org.apache.geronimo.connector.outbound.TCCLInterceptor
                TCCLInterceptor.classLoader --> 
org.apache.geronimo.kernel.config.MultiParentClassLoader 

The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of 
time for us to run out of PermGen space. Currently the task is never cancelled. 
I'm working on cancelling the task. However, that's not sufficient. 
TimerTask.cancel() simply updates state. It doesn't remove the Task from the 
TimerQueue. So, the task lives until it expires (looks like this "feature" is 
fixed in 1.5). Easiest fix is to break the chain of references at the 
IdleReleaser task when the task is cancelled. This should be good enough. 
Alternative is to implement our own Timer -- which wouldn't be too hard... Or 
have multiple Timers and cancel the whole timer...

I'm working on breaking the chain of references at IdleReleaser. Note that this 
means the IdleReleaser classloader will be kept alive until the TimerTask 
expires. However, the IdleReleaser classloader is a long-lived Geronimo class 
loader. So, this shouldn't be a problem, but it's not ideal, either...



  was:


After a deploy/undeploy of DayTrader, the following chain of references (there 
are others which I'm investigating) is keeping a MultiClassLoader instance from 
being marked as available for GC.

java.util.TaskQueue.queue --> java.util.TimerTask[128]
    java.util.TimerTask[5] --> 
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser
      IdleReleaser.this$0 --> 
org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor 
        SinglePoolConnectionInterceptor.next --> 
org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor
          XAResourceInsertionInterceptor.next --> 
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor
            MCFConnectionInterceptor.stack --> 
org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor
              ConnectionTrackingInterceptor.next --> 
org.apache.geronimo.connector.outbound.TCCLInterceptor
                TCCLInterceptor.classLoader --> 
org.apache.geronimo.kernel.config.MultiParentClassLoader 

The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of 
time for us to run out of PermGen space. Currently the task is never cancelled. 
I'm working on cancelling the task. However, that's not sufficient. 
TimerTask.cancel() simply updates state. It doesn't remove the Task from the 
TimerQueue. So, the task lives until it expires (looks like this "feature" is 
fixed in 1.5). Easiest fix is to break the chain of references at the 
IdleReleaser task when the task is cancelled. This should be good enough. 
Alternative is to implement our own Timer -- which wouldn't be too hard... Or 
have multiple Timers and cancel the whole timer...

I'm working on breaking the chain of references at IdleReleaser. Note that this 
means the IdleReleaser classloader will be kept alive until the TimerTask 
expires. However, the IdleReleaser classloader is a long-lived Geronimo class 
loader. So, this shouldn't be a problem, but it's not ideal, either...




> AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps 
> MultiParentClassLoaders alive
> ----------------------------------------------------------------------------------------
>
>          Key: GERONIMO-1125
>          URL: http://issues.apache.org/jira/browse/GERONIMO-1125
>      Project: Geronimo
>         Type: Bug
>   Components: connector
>     Versions: 1.0-M5
>  Environment: JDK 1.4/WinXP
>     Reporter: Kevan Miller
>     Assignee: Kevan Miller
>      Fix For: 1.0
>  Attachments: InterceptorDestroy.patch
>
> After a deploy/undeploy of DayTrader, the following chain of references 
> (there are others which I'm investigating) is keeping a MultiClassLoader 
> instance from being marked as available for GC.
> java.util.TaskQueue.queue --> java.util.TimerTask[128]
>     java.util.TimerTask[5] --> 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser
>       IdleReleaser.this$0 --> 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor 
>         SinglePoolConnectionInterceptor.next --> 
> org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor
>           XAResourceInsertionInterceptor.next --> 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor
>             MCFConnectionInterceptor.stack --> 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor
>               ConnectionTrackingInterceptor.next --> 
> org.apache.geronimo.connector.outbound.TCCLInterceptor
>                 TCCLInterceptor.classLoader --> 
> org.apache.geronimo.kernel.config.MultiParentClassLoader 
> The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of 
> time for us to run out of PermGen space. Currently the task is never 
> cancelled. I'm working on cancelling the task. However, that's not 
> sufficient. TimerTask.cancel() simply updates state. It doesn't remove the 
> Task from the TimerQueue. So, the task lives until it expires (looks like 
> this "feature" is fixed in 1.5). Easiest fix is to break the chain of 
> references at the IdleReleaser task when the task is cancelled. This should 
> be good enough. Alternative is to implement our own Timer -- which wouldn't 
> be too hard... Or have multiple Timers and cancel the whole timer...
> I'm working on breaking the chain of references at IdleReleaser. Note that 
> this means the IdleReleaser classloader will be kept alive until the 
> TimerTask expires. However, the IdleReleaser classloader is a long-lived 
> Geronimo class loader. So, this shouldn't be a problem, but it's not ideal, 
> either...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to