JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-140  -  Node class loader's resource cache should perform proper cleanup
Posted Apr 22, 2013 - updated Dec 27, 2014
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
    lolo4j
  • Category
    Node
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Targetted for
    icon_milestones.png JPPF 3.3.x
Issue description
The class loader's resource cache, which caches resources loaded from the server or client via getResource(), getResources(), getResourceAsStream() or getMultipleResources, saves by default the resources in the file system, as temporary files.

However, even though the files are created with deleteOnExit(), many of them are not actually deleted when the node is terminated. This means the chached resource files may end up filling the default temp folder and trigger all sorts of porblems.

For instance on my current system, in the default_temp_folder/.jppf, I noticed there were 32,500 folders for a total of over 122,000 files and subfolders and a total size of around 4 GB.
Steps to reproduce this issue
Run any normal JPPF application and you will see remaining files in the /tmp/.jppf folder, even after the nodes have been stopped

#2
Comment posted by
lolo4j
May 01, 13:00
The main issue was in LauncherListener where we had: 
public void run() {
  try {
    Socket s = new Socket("localhost", port);
    s.getInputStream().read();
  } catch(Throwable t) {
    System.exit(0);
  }
}
 When the other side of the connection was closed, s.getInputStream().read() would return -1 (EOF) instead of throwing an exception, so the System.exit() was not executed, preventing the shutdown hooks from being run. Thus the cache files were not deleted.

To fix this, we added code to handle the EOF: 
public void run() {
  try {
    Socket s = new Socket("localhost", port);
    int n = s.getInputStream().read();
    if (n == -1) throw new EOFException("eof");
  } catch(Throwable t) {
    System.exit(0);
  }
}
#3
Comment posted by
lolo4j
May 01, 13:04
This is now fixed. Changes committed to SVN trunk revision 2723

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.
#5
Comment posted by
lolo4j
May 09, 05:59
Reopening this bug to backport the fix to branch 3.3
#8
Comment posted by
lolo4j
May 09, 07:14
Fixed in branch b3.3 revision 2729

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.
#10
Comment posted by
lolo4j
May 11, 01:00
Reopening this bug (again) due to additional issues I found in the class loader management. In particular, I found that when a classloader is evicted from the node's class laoder cache, its close() method is not called. This prevents cleanup of the class loader's resource cache.
#12
Comment posted by
lolo4j
May 12, 04:08
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 New to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.