JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-309  -  Jobs with non-serializable task is still executed remotely
Posted Aug 15, 2014 - updated Aug 15, 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
    Not assigned to anyone
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Client
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Always
  • Severity
    Normal
  • Targetted for
    icon_milestones.png JPPF 4.2.1
Issue description
When a client submits a job that has at least one non-serializable task, at least the job header is sent to the server nonetheless. This causes the server to believe the job is ok and to queue it for dispatching.

This creates problems, for instance if the job has a single, non-serializable task: the header will be sent but no task. Since the task count in the header is still 1, the server will not know that the task had a problem.

On the client-side, we capture the NotSerializableException, send a JPPFExceptionResult instead of each task whose serialization fails, then attempt to cancel the job. For some reason, the job cancel sometimes also fails, causing the client connection to hang waiting for a result. As a result, the application code waiting for the job results also hangs.
Steps to reproduce this issue
repatedly submit a job with a single task that is not serializable, e.g. that has a non serializable attribute ==> at some point the code waiting for the results will hang.

#2
Comment posted by
 lolo4j
Aug 15, 10:38
From my testing, I could observe that the job cancellation fails around 1 out 70 times. I can see, using the driver's debug MBean, that the job is still in the queue with the CANCELLED status. I'm suspecting that is because the client is attempting to cancel the job too soon, probably before the JOB_QUEUED event is emitted by the server.

For the 4.2.1 release, I will implement a workaround: the job will not be cancelled. This means that, instead of the non-serializabke task, a JPPFExceptionResult will be sent. Its run() method doesn't do anything but it encapsulats the NotSerializableException via its getThrowable() method, which will be set onot the initial task once it has returned from the node.

This is not a very elegant solution but it will do for a maintenance release. Ideally, what we should do is to not send the task at all and instead set it directly as a job result with its throwable set to the NotSerializableException. The problem here is that the job header is already sent to the server, thus it is expecting the number of tasks specified in the header. One possibility is to send null instead of the task, and modifuy the serve rcode to immediately set this task as completed so it's not dispatched to a node, then send null back to the client, and modify the client code to discard any null task received. This will be done in the trunk and for the next major version. I will create an enhancement for JPPF 5.0 to this effect.
#3
Comment posted by
 lolo4j
Aug 15, 10:51
fixed in: Enhancement JPPF-310 - Improve the handling of non-serializable tasks in the client. was created to follow up on a better solution.