commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SCXML-206) Specification mismatch: event-less transitions are triggered by named events
Date Sun, 07 Sep 2014 19:34:29 GMT

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

Ate Douma commented on SCXML-206:
---------------------------------

Hi Johannes,

I finally had time to look into this and indeed found some issues/bugs with the current implementation.
However, not exactly in the way you describe them.

The crux of the problem is that currently the SCXMLExecutor incorrectly is re-entering its
own execution state when using send.
I'm assuming here you are using the current SimpleScheduler or derivate class.

Part of the refactoring for the Milestone 1 has been to introduce the internal and external
event queues to manage the event processing more appropriately according to the specification.
That work however is not completed yet. The completion of the external IO Processor work I
planned for [Milestone 3|http://commons.apache.org/proper/commons-scxml/roadmap.html].
What I overlooked though was to at least not have the SimpleScheduler directly trigger events
on the SCXMLExecutor (which in addition also was synchronized before), it should now merely
_*add*_ events to the queue. So, instead of calling SCXMLExecutor#triggerEvent it should be
calling SCXMLExecutor#addEvent.
Because of this, you're now seeing re-entrant execution of a single SCXML state machine, which
obviously messes up the internal state.
This is also the cause for SCXML-207. 

I'll commit a fix for the triggerEvent invocation of SimpleScheduler shortly.

Then while testing my fix, I also discovered a new bug in SCXMLSemanticsImpl#matchTransition
which didn't initially cause the problems you saw, but with my fix in SimpleScheduler would
lead to a similar error. Nice :)
So I'll fix that that at the same time.

However I could not reproduce your problem with the state machine getting stuck if no event
is send at all, neither before nor after applying my fixes.
In this regard the specification is IMO pretty clear: enabled event-less transitions must
be executed if no other events are left to be processed.
(which may trigger new events and thus lead to further subsequent event processing)

> Specification mismatch: event-less transitions are triggered by named events
> ----------------------------------------------------------------------------
>
>                 Key: SCXML-206
>                 URL: https://issues.apache.org/jira/browse/SCXML-206
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Johannes Wienke
>            Assignee: Ate Douma
>
> The SCXML 2 specification indicates the following in section 3.13
> {quote}
> A transition is enabled by NULL in atomic state S if a) T lacks an 'event' attribute
b) T's source state is S or an ancestor of S c) T lacks an 'cond' attribute or its 'cond'
attribute evaluates to "true". (Note that such a transition can never be enabled by any named
event.)
> {quote}
> The last aspect that event-less conditions can never be triggered by a named event is
currently violated by the trunk implementation.
> Imagine the following example document:
> {code:xml}
> <scxml xmlns="http://www.w3.org/2005/07/scxml" xmlns:rsb="http://opensource.cit-ec.de/rsb"
> 	version="1.0" initial="Start" name="CustomActionSequential">
> 	<state id="Start">
> 		<onentry>
> 			<log expr="'Starting onentry of state Start'"></log>
> 			<send event="'test'" delay="'100ms'"></send>
> 			<rsb:generic rsb:class="rsb.scxml.LongRunningAction"
> 				name="first"></rsb:generic>
> 			<log expr="'Finished onentry of state Start'"></log>
> 		</onentry>
> 		<onexit>
> 			<log expr="'onexit of state Start'"></log>
> 		</onexit>
> 		<transition target="End">
> 		</transition>
> 	</state>
> 	<final id="End">
> 		<onentry>
> 			<log expr="'onentry of state End'"></log>
> 		</onentry>
> 	</final>
> </scxml>
> {code}
> The rsb:generic action is simply a custom action that wastes some processing time by
sleeping 1 second.
> The logging output that you get when executing this is the following:
> {noformat}
> Aug 29, 2014 11:04:26 AM org.apache.commons.scxml2.model.Log execute
> INFO: null: Starting onentry of state Start
> Aug 29, 2014 11:04:26 AM org.apache.commons.scxml2.model.Log execute
> INFO: null: onexit of state Start
> Aug 29, 2014 11:04:26 AM org.apache.commons.scxml2.model.Log execute
> INFO: null: onentry of state End
> Aug 29, 2014 11:04:27 AM org.apache.commons.scxml2.model.Log execute
> INFO: null: Finished onentry of state Start
> {noformat}
> As you can see, the named event raised by the send action has triggered the transition
since the outputs are not in the expected sequential order. This should not happen according
to the specification.
> On the other hand, if you do not send an event at all, the state machine gets stuck.
This confirms that the transition was actually really triggered by the sent event. Moreover,
it also sounds like a specification mismatch to me. The respective quote from the specification
is:
> {quote}
> After checking the state configuration, the Processor must select the optimal transition
set enabled by NULL in the current configuration. If the set is not empty, it must execute
it as a microstep.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message