commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [SCXML] Multiple transitions based on events
Date Mon, 27 Mar 2006 18:50:21 GMT
On 3/27/06, Heiko.Eichberger@rsbick.rohde-schwarz.com
<Heiko.Eichberger@rsbick.rohde-schwarz.com> wrote:
>
> Hi,
>
> I've downloaded the latest version of SCXML and suddenly I've got some
> errors. I defined some transitions to a state which will be triggered by
> events. But when the state machine is being loaded or when the executor
> starts with "go" there are warnings like the following:
>
> 2006-03-27 16:41:30,511 WARN - 27.03.2006 16:41:30
> org.apache.commons.scxml.env.SimpleErrorReporter onErrorWARNUNG:
> NON_DETERMINISTIC (Multiple conflicting transitions enabled.):  [transition
> (event = ...
>
> 2006-03-27 16:41:30,542 WARN - 27.03.2006 16:41:30
> org.apache.commons.scxml.env.SimpleErrorReporter onError
> WARNUNG: ILLEGAL_CONFIG (Multiple top-level OR states active!): <SCXML> : [
>
<snip/>

As a bit of a window into what this means, the only case where SCXML
semantics allow multiple (simple a.k.a leaf) states to be "active" at
the same time is if they are each part of a (different) region within
a <parallel>. So, for the pruned document below:

<scxml initialstate="alpha" ...>

 <state id="alpha" ... />

 <state id="beta" ... />

 <state id="gamma">
  <parallel id="p1">

   <!-- s1 and s2 are "regions" -->
   <state id="s1">
    <state id="s11" ... />
   </state>

   <state id="s2">
    <state id="s21" ... />
   </state>

  </parallel>
 </state>

</scxml>

it is legal for the state machine to have states "s11" and "s21"
active at the same time (note use of <parallel>), but it is illegal to
have states "alpha" and "beta" active at the same time. The above
error message states that the particular SCXML document being used was
authored such that a scenario similar to the latter one has come about
during execution.

Incidently, I mentioned the "default" policy for handling
non-determinism that is used by Commons SCXML in an unrelated thread
on commons-dev. I will cross-post that here as a hyperlink [1], since
its probably relevant to the discussion (See paragraph beginning with
"As a concrete example" roughly halfway down the post).


> The state definition  looks like this:
>
> ...
>      <state id="mystate1">
>            <onentry>
>            ...
>            </onentry>
>            <transition event="event2" target="mystate2"/>
>            <transition event="event3" target="mystate3"/>
>            ...
>      <state id="mystate2">
>            ...
>
> Did I make something wrong (last week it worked fine)?
>
<snap/>

I don't see anything out of place in this snippet. Can you please post
the smallest possible complete SCXML document that illustrates the
problem? I might then be of more help. ATM, I'm also unsure what
change over the last week could have caused a regression. The
nightlies [2] seem to be still cranking, if we indeed discover an
issue we should wire up your test case to the nightlies as well.

Thanks,
-Rahul

[1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114332465230997&w=2
[2] http://cvs.apache.org/builds/jakarta-commons/nightly/commons-scxml/


> Regards,
>
> Heiko
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message