JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
enhancement_small.png
CLOSED  Enhancement JPPF-168  -  Ability to disable the class cache in the server
Posted Jul 13, 2013 - updated Dec 27, 2014
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Enhancement
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
     lolo4j
  • Category
    Server
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 3.3.x
Issue description
Currently, the JPPF server (or driver) uses a soft references cache to store classes loaded from the connected clients, to make class loading requests from the nodes faster.

This can cause class loading issues in some scpecific scenarios, where the client dynamically loads new versions of the client classes. In this type of situation, since the client uuid does not change, the nodes will not request the new version of these classes if they have already loaded them.

There is a feature in the nodes, to reset the class loader associated with a client, however it only works with classes loaded from the classpath specified in this node class loader. Unfortunately, for classes loaded from the client, the reset is circumvented by the server cache.

Thus, we propose to implement the possibility to disable the server cache such that this reset can take place for classes loaded both locally and remotely by the nodes.

#4
Comment posted by
 lolo4j
Jul 14, 10:35
This is now implemented. The cache can now be disabled by setting "jppf.server.class.cache.enabled = false" in the driver's configuration.

Changes committed to SVN:

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.