JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-153  -  In the node, context class loader and task class loader do not match after first job execution
Posted Jun 04, 2013 - updated Oct 15, 2022
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Node
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Always
  • Severity
    Normal
  • Targetted for
    icon_milestones.png JPPF 3.3.x
Issue description
I have noticed that, upon the 2nd and all subsequent executions of a job by a node, that the context class loader of the thread running a task, is different from the class loader used to load the task. This causes class loading issues when the task uses libraries, such as Spring, which use the thread context class loader.
Steps to reproduce this issue
create a task like this:
public class MyTask extends JPPFTask {
  @Override
  public void run() {
    displayClassLoaders();
  }
 
  private void displayClassLoaders() {
    System.out.println("context class loader = " + Thread.currentThread().getContextClassLoader());
    List<ClassLoader> list = new ArrayList<ClassLoader>();
    ClassLoader cl = getClass().getClassLoader();
    while (cl != null) {
      list.add(0, cl);
      cl = cl.getParent();
    }
    System.out.println("class loader hierarchy:");
    StringBuilder indent = new StringBuilder();
    for (ClassLoader loader: list) {
      System.out.println(indent.toString() + "- " + loader);
      indent.append("  ");
    }
  }
}
Upon the first execution of the task in a node, you will have an output like this:
context class loader = JPPFClassLoader[id=2, type=client, uuidPath=[8C6BD312-0412-628F-0DC7-69D7500B2493, d1], classpath=]
class loader hierarchy:
- sun.misc.Launcher$ExtClassLoader@6b6a3075
  - sun.misc.Launcher$AppClassLoader@6e6dcfde
    - JPPFClassLoader[id=1, type=server, uuidPath=[], classpath=]
      - JPPFClassLoader[id=2, type=client, uuidPath=[8C6BD312-0412-628F-0DC7-69D7500B2493, d1], classpath=]
Upon the second execution, however:
context class loader = JPPFClassLoader[id=2, type=client, uuidPath=[441DA557-A40A-8DA0-7D58-70EC10DB2C14, d1], classpath=]
class loader hierarchy:
- sun.misc.Launcher$ExtClassLoader@6b6a3075
  - sun.misc.Launcher$AppClassLoader@6e6dcfde
    - JPPFClassLoader[id=1, type=server, uuidPath=[], classpath=]
      - JPPFClassLoader[id=3, type=client, uuidPath=[504F646E-B78F-CB6E-BE96-5738FD7EB019, d1], classpath=]
Here the context class loader should be the one with id=3, but it is the same as for the previous execution!

#2
Comment posted by
 lolo4j
Jun 04, 20:39
A workaround for this issue is to set the context properly when the task starts:
public class MyTask extends JPPFTask {
  @Override
  public void run() {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
    ...
  }
}
#5
Comment posted by
 lolo4j
Jun 09, 21:55
Fixed changes committed to SVN:

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from Confirmed to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • Information about the user working on this issue has been changed, from lolo4j to Not being worked on.