Why worker thread transitions from CANCELLED to SCHEDULED skipping READY? (JavaFX2) - multithreading

Question

Update: I am finding the problem with other threads too; they enter Scheduled state but never transition to Running. why?
My program has a Service that uses a Task to connect to a device through the serial port.
In other words,
public class ConnectService extends Service<String> {
protected Task createTask() {
return new ConnectTask();
}
class ConnectTask extends Task<ObservableList<String>> {
#Override
protected ObservableList<String> call() throws Exception {
...
connect();
...
}
}
}
If a previous call to connect to the device got hung, then I want to cancel the task/thread and start over afresh in this attempt.
In order to do this,
if (connectService.getState() != Worker.State.READY) {
connectService.cancel();
}
connectService.restart();
However in the debugger I am finding that if the state is SCHEDULED, then the above code sends it to CANCELLED. But restart() will not send it to READY - instead it goes back to SCHEDULED - and call() does not get executed!
This seems to contradict the docs here
A reusable Worker will transition from CANCELLED, SUCCEEDED or FAILED
back to READY.
I tried
if (connectService.getState() != Worker.State.READY) {
connectService.cancel();
connectService.reset();
}
connectService.start();
Now state goes back to READY, but call() is never executed!

Answer 1

You need to add Worker.State.SCHEDULED to the states excluded from your if condition, i.e.
if (connectService.getState() != Worker.State.READY &&
connectService.getState() != Worker.State.SCHEDULED) {
connectService.cancel();
}
connectService.restart();
This is because the Worker will always transition from READY to SCHEDULED before it enters the RUNNING state. From the docs
However even in cases where the Worker is executed immediately, the
Worker will temporarily enter the SCHEDULED state before entering the
RUNNING state. That is, the transition is always from READY to
SCHEDULED to RUNNING (unless of course the Worker in cancelled).
If for some reason your working is stuck in the SCHEDULED state, it's likely that the cancel and restart just returns it to the same stuck state.
Also, (not seeing the rest of your code, so this is just extrapolation) the idea of interrupting it when you catch it running on the assumption that it is hung seems shaky, since it could be working well but taking longer than expected, or it could be hanging every time you call it. If there's no test you can run within connectService to determine whether it's hung or not, then I guess you're stuck with something like this, but it feels problematic.