commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <>
Subject [jira] [Commented] (SCXML-207) Race condition in transition notification for SCXMLListeners
Date Sun, 07 Sep 2014 20:21:28 GMT


Ate Douma commented on SCXML-207:

This issue is caused by the same problem as discovered, and fixed, by SCXML-206.

An SCXML state machine is not supposed to be executed concurrently from multiple threads.
This is by design and by the spec.
I'm not sure where you saw this to be 'ok' in the online documentation, but if this is in
the Commons SCXML documentation then it should be removed.
Note the old Commons SCXML (0.9) implementation didn't allow this either but enforced this
through synchronized methods. 
So while with the old Commons SCXML you could (try to) invoke the engine from multiple threads,
they were serialized nonetheless.
The new Commons SCXML implementation no longer uses synchronized methods and leaves it up
to the client code not to trigger events concurrently (should use #addEvent instead).   

Regarding the lookup of the 'current' event name from the system context (and why not use
the event name from Transition):
This is according to the specification, see the description of *_event* in section [5.10 System
The SCXML Processor MUST bind the _event variable when an event is pulled off the internal
or external event queue to be processed, and MUST keep the variable bound to that event until
another event is processed. [...] In the case of <transition> elements that do not contain
an 'event' attribute and the <onexit> and <onentry> handlers of any states that
are exited or entered by such transitions, the _event variable will not have a easily predictable
value since the transition is not being driven by an event. In these cases, _event will be
bound to the last event that was matched against a transition.
Also note that the event name in the Transition might not (exactly) match the 'current' event
name: it might have been matched on prefix only, or maybe even be the '*' match all event

> Race condition in transition notification for SCXMLListeners
> ------------------------------------------------------------
>                 Key: SCXML-207
>                 URL:
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Johannes Wienke
>            Assignee: Ate Douma
> When using a SimpleSCXMLListener we have seen impossible transitions occur in the log
output of that listener. After digging around the source code I can see the issue that results
in theses outputs.
> In order to derive the event name passed as the last argument to SCXMLListener#onTransition,
the following code inside SCXMLSemanticsImpl is used:
> {code:java}
> public void notifyOnTransition(final SCXMLExecutionContext exctx, final Transition t,
>                                       final TransitionTarget target) {
>     EventVariable event = (EventVariable)exctx.getScInstance().getSystemContext().getVars().get(SCXMLSystemContext.EVENT_KEY);
>     String eventName = event != null ? event.getName() : null;
>     exctx.getNotificationRegistry().fireOnTransition(t, t.getParent(), target, t, eventName);
>     exctx.getNotificationRegistry().fireOnTransition(exctx.getStateMachine(), t.getParent(),
target, t, eventName);
>     }
> {code}
> When triggering events on the engine from multiple threads (which is ok according to
the online documentation), a different thread might have already replaced the contents of
the SCXMLSystemContext.EVENT_KEY context item and hence a wrong event name might be used from
this point on.
> Actually, I don't even understand why the event name is looked up from the context here
at all, since is already available inside the transition.

This message was sent by Atlassian JIRA

View raw message