[jira] [Commented] (SCXML-207) Race condition in transition notification for SCXMLListeners

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SCXML-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125046#comment-14125046 ] 

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 Variables|http://www.w3.org/TR/scxml/#SystemVariables]:
{quote}
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.
{quote}
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 name.


> Race condition in transition notification for SCXMLListeners
> ------------------------------------------------------------
>
>                 Key: SCXML-207
>                 URL: https://issues.apache.org/jira/browse/SCXML-207
>             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
(v6.3.4#6332)