We can distinguish 2 use cases:

1) One of the drivers is used solely as failover, as is the case in the originating forum thread. In this situation an easy fix would be to make the other driver server mark it as a peer (e.g. "jppf.driver.peer = true") in the information available to execution policies. Then it is enough to set the job with an appropriate exeuction policy to work around the issue, like this:

JPPFJob job = new JPPFJob();
job.getSLA().setExecutionPolicy(new Equal("jppf.peer.driver", false));

This is the solution I will implement for JPPF 3.3.7 as it satisfies the scenario in the forum thread.

2) In the general case, for instance when the peer initially has some nodes attached, then for any reason the nodes get disconnected, there are several possibilities:

• in the more recent versions, we can use a job dispatch timeout to cause the job dispatch to be resubmitted and hope that it will be resubmitted to a driver with nodes attached
• a more efficient, but more complex and time-consuming, solution, would be to have a monitoring of the peer driver so the submitting driver knows how many nodes it has and can choose to reject it for scheduling. I might register this as a new feature for JPPF 5.2, as we are already horribly late for 5.1.

Fixed in:

• trunk revision 3829
• branch b5.0 revision 3830
• branch b3.3 revision 3831