On 02-09-14 12:58, Johannes Wienke wrote:
Hi,
On 08/29/2014 12:39 PM, Johannes Wienke wrote:
we are currently evaluating commons scxml in the trunk version for our
purposes. On thing that confused us is the fact that transitions from a
state can already occur while that state's onentry executable content is
still processing. Hence, we end up with more parallelism than expected.
Is this the intended behavior?
From the SCXML specification I actually cannot find anything that either
allows or prevents this interpretation. So I am also curious how this
behavior is justified wrt. to specs.
Following up on this: We have found a statement in the SCXML
specification that disallows the current behavior. In section 4.10 the
specification states:
"Note that SCXML treats the executable content triggered by a transition
as a single blocking operation and that no events are processed until
all the executable content has completed. For example, when taking a
transition into state S, the SCXML processor will not process any events
or take any transitions until all <onentry> handlers in S have finished."
This is definitely not the case right now when using multiple threads to
trigger events.
Hi Johannes,
Please see my comments and fixes for SCXML-206 and SCXML-207.
The problems you were seeing were caused by erroneous and incorrect (internal!)
concurrent execution of the same state machine instance, which as you correctly
stated above is not allowed.
From a design point of view: why do the client threads that trigger
events directly process the whole event transition logic instead of
using an internal event queue and a processing thread as proposed by the
SCXML specification?
Actually, Commons SCXML already uses an event queue (one for internal events and
one for external events).
It is however the responsibility of separate client threads to only use the
executor #addEvent methods and only use a single client thread for actual
execution and event triggering on the state machine.
The bug you encountered was in the Commons SCXML *internal* delivery of events
which likewise (now) should use #addEvent but still used the #triggerEvent
method instead. This should now be fixed.
Regards, Ate
Cheers,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
