commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [scxml] bug with script in combination of a chain of transitions
Date Tue, 30 Jun 2015 20:43:16 GMT
Hi Rinke,

I just had time to look at your example, and quickly discovered where the 
problem is.

Further comments inline below.

Regards, Ate

On 2015-06-15 22:37, R.C. Hoekstra wrote:
> Hi Woonsan, hi others,
>
> At first, sorry for the late reply. I posted the issue in april, but didn't get a response
in the first two weeks. Then I forgot about it (busy with other issues), and then just saw
your reply, about a week ago.
>
> Anyway, I've been thinking hard about the issue, and I think I now understand what is
going on here.
>
> Then again, sorry that my example wasn't so clear, at first. The problem is we're having
very complicated scxml schemes working with several custom classes, and I tried to bring the
example back to the basics, but probably just missed the key thing.
>
> It basically comes to this, I discovered. Consider this scxml:
>
> <state id="bla">
>         <transition event="screening" target="cxr" />
> </state>
>
> <state id="cxr">
>          <onentry>
>                   <ntd:test id="CXR" />
>          </onentry>
>          <transition event="CXR.negative" target="untreated" />
>          <transition event="CXR.positive" target="somethingelse"/>
> </state>
> <state id="untreated" />
>
> The custom ntd:test tag fires a CXR.negative event.
>
> Now the SCXMLListener reports this for the onentry's and onexit's
>
> ...
> 0.000: Human#0 ONEXIT bla
> 0.000: Human#0 ONEXIT cxr
> 0.000: Human#0 ONENTRY untreated
> 0.000: Human#0 ONENTRY cxr
>
> Note that the problem is that the cxr state's onexit is reported first, and only at the
end of the chain the onentry for cxr is reported. The order should have been this:
> onexit bla
> onentry cxr
> onexit cxr
> onentry untreated
>
> This doesn't happen with logs, it only happens with my own custom action.
>
> The custom action does some tests, and on basis of the state the engine is in, and has
been in (and some other stuff) the outcome is positive or negative.
> It then sends back a positive or a negative event, via this code:
>
>
>              TriggerEvent[] evts = { new TriggerEvent(stateMachineEvent, TriggerEvent.SIGNAL_EVENT,
payload) };

>              scxmlExecutorInstance.triggerEvents(evts);

Here is the culprit: you cannot and may not invoke triggerEvents (reentrant) 
from the thread executing the statemachine itself.
SCXML, by specification, is strictly sequential in processing (to ensure 
deterministic behavior).
What you should do instead is adding your event to the internal event queue of 
the statemachine from within your custom action like:

     @Override
     public void execute(ActionExecutionContext exctx) throws ModelException, 
SCXMLExpressionException {
         ...
         TriggerEvent evt = new TriggerEvent(stateMachineEvent, 
TriggerEvent.SIGNAL_EVENT, payload);
         exctx.getInternalIOProcessor().addEvent(evt);
     }

This will queue your event to be processed during (at the end of) the current 
external event processing, before control is returned back to the statemachine 
invoker.

Alternatively, you also can add the event to the external IO event queue via 
scxmlExecutorInstance.addEvent(evt).
That will queue your event to be processed after the current (and possible other 
pending) external event processing.

Or you can even use the ActionExecutionContext.getEventDispatcher() and dispatch 
your event indirectly. In that case you might want to take a look at the Send 
class implementation for example.

HTH, Ate


>
> where stateMachineEvent is either "<id>.positive" or "<id>.negative".
>
>
> So what happens is this:
> 1) state machine exits "bla" -> onexit bla is reported by listener
> 2) state machine enters "cxr", and goes straight to onentry
> 3) custom action is executed, scxmlExecutorInstance.triggerEvents is called with "CXR.negative".
> 4) Still as part of the custom action, the event is caught in the transition tag, and
state machine directed to "untreated"
> 5) the "cxr" state is exited -> onexit cxr reported by listener
> 6) "untreated" state entered -> onentry untreated reported by listener
> 7) Now that the state of the scxmlExecutoerInstance.triggerEvents call is reached, only
now the custom Actions's execute method is returned.
> 8) only after the execute method of the custom action returned, the onentry block of
"cxr" is finished, and only after that the "onentry cxr" is reported by the listener.
>
>
> So, conclusion:
>
> A) does this scenario make sense?
> B) would you consider this as a bug? The behavior is at least tricky...
>
>
> Thanks, Rinke
>
>
>
>
> ________________________________________________________________________________________
>
> Hi Rinke,
>
> Did you run with commons-scxml2-2.0-SNAPSHOT?
> I've tried to run the following similar to yours on latest revision, but the result seems
> different from what you're seeing:
>
> <?xml version="1.0" ?>
> <scxml xmlns="http://www.w3.org/2005/07/scxml"
>         version="1.0"
>         datamodel="jexl"
>         initial="test1">
>
>    <state id="test1" initial="test1.1">
>
>      <state id="test1.1">
>        <onentry>
>          <log expr="'logging in test1.1'" />
>        </onentry>
>        <transition event="test1.1.positive" target="test1.2"/>
>      </state>
>
>      <state id="test1.2">
>        <onentry>
>          <log expr="'logging in test1.2'" />
>        </onentry>
>        <transition event="test1.2.positive" target="test1.3"/>
>      </state>
>
>      <state id="test1.3">
>        <onentry>
>          <log expr="'logging in test1.3'" />
>        </onentry>
>      </state>
>
>    </state>
>
> </scxml>
>
> I removed the custom action tags and replaced the script tag with simple log tags.
> And I see the following when I tested it with the stanadlone tool [1]:
>
> $ ./scxml.sh test.scxml
> <?xml version="1.0" encoding="UTF-8"?><scxml xmlns="http://www.w3.org/2005/07/scxml"
> xmlns:cs="http://commons.apache.org/scxml" version="1.0" initial="test1" datamodel="jexl">
> ---- >8 ---- >8 ----
> </scxml>
>
> May 05, 2015 11:44:51 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onEntry
> INFO: enter /test1
> May 05, 2015 11:44:51 PM org.apache.commons.scxml2.model.Log execute
> INFO: null: logging in test1.1
> May 05, 2015 11:44:51 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onEntry
> INFO: enter /test1/test1.1
> test1.1.positive
> May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onExit
> INFO: exit /test1/test1.1
> May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onTransition
> INFO: transition (event = test1.1.positive, cond = null, from = /test1/test1.1, to =
/test1/test1.2)
> May 05, 2015 11:45:16 PM org.apache.commons.scxml2.model.Log execute
> INFO: null: logging in test1.2
> May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onEntry
> INFO: enter /test1/test1.2
> test1.2.positive
> May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onExit
> INFO: exit /test1/test1.2
> May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onTransition
> INFO: transition (event = test1.2.positive, cond = null, from = /test1/test1.2, to =
/test1/test1.3)
> May 05, 2015 11:45:47 PM org.apache.commons.scxml2.model.Log execute
> INFO: null: logging in test1.3
> May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener onEntry
> INFO: enter /test1/test1.3
>
> (I typed 'test1.1.positive' and 'test1.2.positive' to trigger those events manually.)
>
> So, the execution order is as follows:
> 1. enter into test1 state
> 2. execute actions in onentry of test1.1 state
> 3. enter into test1.1 state and wait
> 4. 'test1.1.positive' event triggered manually
> 5. exit from test1.1 state
> 6. transition from test1.1 to test 1.2 state
> 7. execute actions in onentry of test1.2 state
> 8. enter into test1.2 state
> 9. 'test1.2.positive' event triggered manually
> 10. exit from test1.2 state
> 11. transition from test1.2 to test1.3 state
> 12. execute actions in onentry of test1.3 state
> 13. enter into test1.3 state
>
> I don't think <script> action would be different from <log> action in execution
> ordering, so I think you're seeing a different result on your end for some reason. Maybe
you
> can try to find what the difference comes from?
>
> Regards,
>
> Woonsan
>
> [1] http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html
>
>
> --------------------------------------------
> On Fri, 4/17/15, R.C. Hoekstra <r.c.hoekstra@erasmusmc.nl> wrote:
>
>   Subject: [scxml] bug with script in combination of a chain of transitions
>   To: "user@commons.apache.org" <user@commons.apache.org>
>   Date: Friday, April 17, 2015, 4:12 AM
>
>   Dear people at scxml,
>
>   I found a bug in the scxml commons project.
>
>   Consider this scxml file:
>
>       <state id="test1" initial="test1.1">
>           <state id="test1.1">
>               <onentry>
>
>   <ntd:test id="test1.1" isIn="test1.1" />
>
>   <script> agent.storeInMemory("test1.1");
>   </script>
>               </onentry>
>               <transition
>   event="test1.1.positive" target="test1.2"/>
>           </state>
>           <state id="test1.2">
>               <onentry>
>
>   <ntd:test id="test1.2" isIn="test1.1" memory="true"
>   />
>               </onentry>
>               <transition
>   event="test1.2.positive" target="test1.3"/>
>           </state>
>           <state id="test1.3"/>
>       </state>
>
>   There is a custom tag, which simply tests if the state
>   machine is at present in the state specified in the "isIn"
>   attribute. If it is, it sends an event <id>.positive,
>   else it sends <id>.negative.
>   The purpose of this is that we needed a memory: a test that
>   the state machine has at any moment been in a certain state.
>   That is done via the script tag: via the
>   agent.storeInMemory("test1.1") call, the test1.1 state is
>   stored in the memory of the agent, and ntd:test tag
>   considers this memory if the memory=true attribute is
>   specified. As the state test1.1 is stored in memory while
>   being in state test1.1, the test of test1.2 should return
>   positive, and the test1.2.positive event should be send.
>
>   However, this tests fails.
>   The problem is that the script tag appears to be only
>   executed AFTER the chain of all transitions has been
>   executed and finished, and so the call of the script is too
>   late for the test.  I had expected the script tag to be
>   executed at entering state test1.1, and not only after
>   having passed test1.1 and being already in test1.2
>
>
>   The order of entries is also weird: the log shows this
>   order:
>
>   onentry: test1
>   onentry: test1.2
>   onentry: test1.1
>
>   So you should expect that the onentry for 1.2 happens after
>   1.1, but it is reversed.
>
>   best regards, Rinke
>
>
>   ---------------------------------------------------------------------
>   To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>   For additional commands, e-mail: user-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>


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


Mime
View raw message