Re: Re: Re: [scxml] bug with script in combination of a chain of transitions
Hi Ate, Ah, I understand the issue now. Thanks for looking at it. best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] bug with script in combination of a chain of transitions
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
Re: Re: [scxml] bug with script in combination of a chain of transitions
Hi Ate, Sorry I forgot to mention, it's 2.0-SNAPSHOT. Thanks for looking at it. best regards, Rinke Date Mon, 22 Jun 2015 23:10:21 GMT Hi Rinke, I will try to take a look at your issue later (end of) this week. It would be helpful if you can report against which version you are experiencing this behavior: current 2.0-SNAPSHOT or earlier milestone 2.0-M1 or 2.0-M0? Thanks, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] bug with script in combination of a chain of transitions
Hi Rinke,
I will try to take a look at your issue later (end of) this week.
It would be helpful if you can report against which version you are experiencing
this behavior: current 2.0-SNAPSHOT or earlier milestone 2.0-M1 or 2.0-M0?
Thanks, 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);
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:
Re: Re: [scxml] bug with script in combination of a chain of transitions
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);
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
Re: [scxml] bug with script in combination of a chain of transitions
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.hoeks...@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
