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.

fixed in:

• trunk revision 3327
• branch b4.2 revision 3327

Enhancement JPPF-310 - Improve the handling of non-serializable tasks in the client. was created to follow up on a better solution.