JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-154  -  Issues when the client disconnects while a node has active class loading requests
Posted Jun 08, 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
    lolo4j
  • Category
    Client
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Always
  • Severity
    Normal
  • Targetted for
    icon_milestones.png JPPF 3.3.x
Issue description
When a client gets disconnected from the driver and at the same time a node is waiting for the response to a class loading request, generally while deserializing a task submitted by this client, I have observed two incorrect outcomes of the job submission:
  • in one case, after client reconnection the job is returned with all tasks non-exececuted, thus with getException() == null and getResult() == null
  • in the other case, after reconenction to the driver, the client hangs and never returns the job's results.
Steps to reproduce this issue
Use the attached code sample, which triggers a client disconnection while the node is deserializing a task.

This works with a local node and driver.

#2
Comment posted by
lolo4j
Jun 08, 07:43
A file was uploaded. reproducing sample codeicon_open_new.png
#4
Comment posted by
lolo4j
Jun 08, 08:25
Found the issue for the first bullet point in the description.

This problem is caused by our use of the not found cache. If the client is disconnected while the node is waiting for a class in this client, the server returns a response to the node with a null content and a state = JPPFResourceWrapper.State.NODE_RESPONSE_ERROR. The class name gets add to the not found cache. Thus, subsequent attempt to load this class will trigger a ClassNotFoundException. This is because in the current code in AbstractJPPFClassLoader.findClass(String, boolean) we have: 
if (resource != null) notFoundCache.add(name);
 Note how we do not take the resource state into account smileys/4.png Now, when using this code instead: 
if ((resource != null) && (resource.getState() != JPPFResourceWrapper.State.NODE_RESPONSE_ERROR)) notFoundCache.add(name);
 the task gets finally executed and returns normally with its result set.

#5
Comment posted by
lolo4j
Jun 08, 08:44
The first scenario is resolved. It was happening when the client application was closing both the class laoder channel and the job channel (doing a close() on the respective Sockets).

The second scenario only occurs when only the socket of the class loader channel is closed. Then, the client hangs waiting for the job results.
#7
Comment posted by
lolo4j
Jun 09, 22:26
In the second scenario, what happens is that when the class loader channel is closed, the server automatically closes the associated job channel (using the connectionUuid correlation). The problem is that the job is not cancelled nor removed from the queue, where it just hangs.
#8
Comment posted by
lolo4j
Jun 09, 22:34
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.