JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
CLOSED  Feature request JPPF-184  -  Optimize deserialization errors handling in the node
Posted Aug 29, 2013 - updated Oct 03, 2013
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
    Feature request
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Node
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 4.0
Issue description
Currently when a node is receiving a task bundle from the server, and when there is any task in the bundle that cannot be deserialized, then none of the tasks will be executed, even if some of them could be deserialized without error. In this case, the node will send back a job header with no task and the first Throwable that was raised during deserialization. The server will then send this exception back to the client, along with the non-executed tasks.

We propose to introduce a smarter handling of this use case, such as executing the tasks that could be deserialized. The tasks whose deserialization failed would then be replaced with instances of JPPFExceptionResult describing as much of the error as possible. This would have at least the stack trace of the throwable. The class of the task may not even be available.

#3
Comment posted by
 lolo4j
Oct 03, 07:26
This issue is resolved by Enhancement JPPF-190 - Improve handling of deserialization errors in the nodes

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.