[jboss-dev-forums] [Design of POJO Server] - Classloader leak in BasicThreadPool

[bstansberry@jboss.com]

Discussion of solution to http://jira.jboss.org/jira/browse/JBCOMMON-41[/url] .  For background on the problem see [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&t=129122 .

I intend to solve this by having the BasicThreadPool set an appropriate TCCL on the pool thread:

1) in the ThreadPoolFactory, just after creating the thread.
2) when a thread is returned from a task, by subclassing ThreadPoolExecutor and overriding afterExecute().

What TCCL gets set will be configurable by an injectable policy:


  | package org.jboss.util.loading;
  | 
  | public interface ClassLoaderSource {
  | 
  |    /**
  |     * Returns the classloader provided by this object; may return null.
  |     */
  |    ClassLoader getClassLoader();
  | 
  | }
  | 

If no ClassLoaderSource is injected, the TCCL will be set to null.

In common-core I'll add a basic SimpleClassLoaderSource which simply returns getClass().getClassLoader().  In the AS, that would return the classloader that loads $JBOSS_HOME/lib.

Somewhere else, (AS server module?) I'll add another impl that exposes a start() and stop() method.  In start it will cache a weak ref to the current TCCL, and will thereafter return that.  This could be injected into the jboss.system:service=ThreadPool pool; it will return the classloader in effect when conf/jboss-service.xml is deployed.  That seems like a reasonable default for that service, or at least is likely closest to the "typical" behavior of the current thread pool.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128107#4128107

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128107