commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [SCXML] onentry executable content parallel to further transitions
Date Sun, 07 Sep 2014 20:31:27 GMT
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:
For additional commands, e-mail:

View raw message