[jboss-jira] [JBoss JIRA] (AS7-3737) Threads ContextClassLoader leak caused by EJB passivation pool

[Paul Ferraro (JIRA)]

     [ https://issues.jboss.org/browse/AS7-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated AS7-3737:
------------------------------

       Fix Version/s: 7.1.0.Final
    Git Pull Request: https://github.com/jbossas/jboss-as/pull/1513  (was: https://github.com/jbossas/jboss-as/pull/1513)
     Forum Reference: https://community.jboss.org/thread/195134  (was: https://community.jboss.org/thread/195134)

    
> Threads ContextClassLoader leak caused by EJB passivation pool
> --------------------------------------------------------------
>
>                 Key: AS7-3737
>                 URL: https://issues.jboss.org/browse/AS7-3737
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.0.CR1b
>         Environment: Seam 2.2.2 application
>            Reporter: Philippe Guinot
>            Assignee: Paul Ferraro
>              Labels: ContextClassLoader, PassivatingBackingCacheImpl, Threads, ejb, leak, passivation, pool, thread
>             Fix For: 7.1.0.Final
>
>
> The EJB passivation pool, created at startup, is actually activated only at first use, when an EJB gets passivated. This cause the pool's thread keeping in its context a reference to the context class loader. When the passivation is called, the context class loader is the application class loader.
> This actually cause the server keeping a thread which still refers to an application's class loader, even when the application is undeployed.
> To avoid such a leak, I changed a few things in org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl
> a) In the constructor PassivatingBackingCacheImpl(StatefulObjectFactory<V>, BackingCacheEntryFactory<K, V, E>, ReplicationPassivationManager<K, E>, BackingCacheEntryStore<K, V, E>, ThreadFactory, ScheduledExecutorService), after
> {code} this.executor = executor;{code}
> I added:{code}
> if (this.executor != null) {
> 	this.executor.execute(new Runnable(){
> 	   public void run()
> 	   {
> 	   }});
> }{code}
> b) In the methodstart(), after
> {code} this.executor = Executors.newScheduledThreadPool(1, this.threadFactory);{code}
> I added: {code}
> if (this.executor != null) {
> 	this.executor.execute(new Runnable(){
> 	   public void run()
> 	   {
> 	   }});
> }{code}
> This only works because the pools contains only 1 thread.
> In addition to this, it seems that the references to the EJB is sometimes not cleaned at undeploy. To do so, I had to change in the stop method:
> {code}
> if (this.threadFactory != null) {
>     this.executor.shutdownNow();
> }
> {code}
> to
> {code}
> if (this.executor != null) {
>     this.executor.shutdownNow();
> }
> {code}
> Looks like a bug, but I'm not really sure. Anyway, this cleaned the reference to the EJB in the current pool task.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira