Open azhuchkov opened 3 years ago
It seems that recreating state machine and resetting it to persisted state solves the issue. Just resetting existing instance didn't help.
In any case it looks like FSM dumps (toString()) show sane current state, the problem is interceptor starts receiving weird states.
BTW, I use DefaultStateMachineService for managing state machines and do not call release.
One more observation: provisioning FSM every time new event arrives with subsequent stop creates circular dependency if some action need to send event: [eventService <-- action <-- stateMachineFactory <-- eventService]. Technically it can be solved introducing some buffer, like BlockingQueue, but it does not look good enough.
So, what is a way to go to implement long-running tasks management using FSM with persistence and timers?
I have bunch of long-running jobs which are managed using state machines.
Here is the diagram describing process:
Then I use
StateMachineRuntimePersister
to persist job state into RDBMS - particularly methodpreStateChange
to prevent state transition in case of failure.The first weird thing I encounter is that after transition from
TASK_FAILED
(triggerless or by timer) states become composite, e.g.getIds()=[PREPARATION, URL_RESOLVING]
(on first pass I seegetIds()=[PREPARATION]
).What is worse after this transition I have
getIds()=[EXECUTION, TASK_FAILED]
, like if internal state ofEXECUTION
superstate has not been reset to initial state. Nevertheless the next state change is toTASK_PROPOSED
(which impossible to reach directly fromTASK_FAILED
), so it looks like despite all the weird things interceptor sees, FSM still works.Version used: 3.0.0
Parameters passed to interceptor's
preStateChange()
onTASK_ERROR
message and further: