JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Enhancement JPPF-68  -  Node: separation of class loader instances and driver connection
Posted Sep 18, 2012 - updated Dec 27, 2014
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
  • Status
  • Assigned to
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Targetted for
    icon_milestones.png JPPF 3.3
Issue description
It would be nice to minimize impact of unreachable driver in node. Every attempt to connect driver class server leads to new JPPFClassLoader and ResourceCache allocation.
  JPPFClassLoader should be created after/during successful connection to driver.

Comment posted by
Jan 29, 07:41
In addition, it would be great to be able to reset a client class loader (in effect create a new class loader instance) without having to disconnect and reconnect the node.

This would allow a much more flexible class path management, as it would be possible to change or remove elements of the classpath (i.e. new libraries or new versions of existing libraries), on the fly with a minimal impact.
Comment posted by
Jan 31, 09:32
I have refactored the class loader code so now the class loader code is completely separate from its connection to the driver. Committed to trunk revision 2624.

What remains to do is to implement the mechanism that will allow creating a new class loader instance for the same server or client (based on uuid path) "on the fly", before the tasks are desrialized in the node. This will allow to change or remove existing classpath elements without having to disconnect/reconnect to the driver. The classpath will ned to be rebuilt via calls to AbstractJPPFClassLoader.addURL().

Also, we need to make sure that the resource cache in the server is cleared or reset for the given uuidPath, otherwise some class loading requests will never reach the client and be served by the driver directly.
Comment posted by
Feb 16, 09:05
This enhancement is now implemented. Changes committed to SVN trunk revision 2636

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from New 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.