commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [scxml] stop and resume by serializing the executor does not work
Date Sat, 03 Jul 2010 16:43:19 GMT
On Fri, Jul 2, 2010 at 7:04 PM, RT <> wrote:
> I tried your suggestion -  executor.getCurrentStatus().getStates() - in a few
> places and I noticed something interesting.

OK, reading the content below, this isn't a serialization round trip
issue then (that would've been unexpected). OTOH, the behavior you
note below is expected, and hence my suggestion was to introspect
executor's active state in the "fireEvent" method from your previous
email (and not in onEntry or custom actions).

> So, using the context explained in my prev email, (without the
> serialization/deserialization):
> 1. state machine starts
> 2. onEntry() gets called for stateA - here I call the executable content for
> this state - something similar to what AbstractStateMachine does
> 3. Executable content for StateA completes
> 4. After a few mins - trigger event "gotoB"
> 5. onEntry() gets called for stateB - before calling the executable content,
> I inspect executor.getCurrentStatus().getStates(). Surprisingly, the only
> active state here is "stateA". How is that possible? Does the
> executor.currentStatus object get updated after the listeners kick-in?

Thats the original behavior from Commons SCXML's first release, where
the active state(s) were changed after considering all event
processing steps to be "atomic", and only after all steps were
completed the active state(s) within the executor would be updated.
Therefore, its best to check the executor's active state(s) in your
"fireEvent" method after (or replacing) the System.out.println line.

The current expectation from the SCXML spec is that the active
state(s) would be updated before the onEntry custom actions and
listeners. The behavior of the library will be updated to match in a
subsequent release.

> My stop&resume logic with the serialized executor kind of depends on the
> agreement that "stateB" would be in the list of activeStates while queried
> in in the onEntry of a listener. Here's how:
> a. onEntry() called for stateA
> b. store stateA as the last known state of the state machine
> c. save a serialized version of the executor to the database
> d. invokeExecutableContentForA()
> e. exit onEntry() handler
> If the app crashed while in step c and we try to resume again
> f. check the last known state in the database - in this case stateA
> g. here I have a map that tells me what event I need to trigger - in this
> case gotoB
> h. deserialize the executor from the database
> i. executor.triggerEvent("gotoB")

Correct, and you can still do all this, with the change that step (b)
-- and perhaps (c) -- above would be performed in "fireEvent" and not


> While debugging the flow of control in the executor after this triggerEvent
> is called, I see that we try to find a match for a transition with this
> event from the parent of stateA - not from stateA and thats why I never saw
> any transitions happening.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message