You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Lorenz Schumann | Sysvision GmbH <lo...@sysvision.de> on 2010/09/24 17:34:22 UTC
[scxml] Too many state navigation causes StackOverflowException
Hi,
i am using Commons SCXML for the first time and am overall new to the
Statechart paradigm.
But i am working on a software where a statemachine is needed and the
first choice fell on commons.
So much for the introduction.
Now what we discovered is that when you navigate from state to state via
triggering events there is a recursion that makes the method-stack
higher and higher and will at some point throw an StackOverflowError.
This is what the important part of a stacktrace looks like:
at
org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
at
org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
at
org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
at MyInvoker.invoke(MyInvoker.java:23)
at
org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
at
org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
at
org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
at MyInvoker.invoke(MyInvoker.java:23)
at
org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
at
org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
at
org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
at MyInvoker.invoke(MyInvoker.java:23)
Are we using it as it is meant to be? Is there a way that the execution
of states is not beeing stacked?
Help is much appreciated.
Lorenz
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] Too many state navigation causes StackOverflowException
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Sep 28, 2010 at 10:29 AM, Rahul Akolkar <ra...@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 6:40 AM, Lorenz Schumann | Sysvision GmbH
> <lo...@sysvision.de> wrote:
>> Hi Rahul,
>>
>> i took over a project in development and took the implementation as the
>> correct way to do it.
>> But after i read your response (thank you very much by the way!) i re-read
>> everything in the documentation.
>>
>> I want to control a phone application with what scxml can offer me.
>> But when i look at the stopwatch example i see a huge difference to our
>> approach: When controlling a stopwatch the states change on user action
>> (mostly). The user interface sends the events to the statemachine.
>> But in our phone application the states change depending on what happens
>> inside the invoked code. So we trigger the events inside the invoked code.
>> I know there is some fraction of the puzzle i am missing and i cannot see
>> how to fire the events from outside to control the statemachine.
>>
> <snip/>
>
> I think part of it is that you have started with one of the most
> flexible and thereby, harder constructs i.e. invoke to work with. If
> the code that you are invoking isn't long running, then you are better
> off using constructs that allow for easier synchronous usage for
> triggering events.
>
>
>> I also couldn't find any helpful examples. Anything that helps is
>> appreciated!
>>
> <snap/>
>
> There is an example (related to mobile apps) linked from the home
> page, see "Who is using it?" section:
>
> http://commons.apache.org/scxml/
>
> Some details here, code is invoked using custom actions (not using invoke):
>
> http://mymobileweb.morfeo-project.org/mymobileweb/mymw-tech/scxml
>
<snip/>
Or this instead:
http://forge.morfeo-project.org/wiki_en/index.php/SCXML_Getting_Started
-Rahul
> I pointed to the guide in the previous email, which has more on custom actions.
>
>
>> Thanks in advance!
>>
>> Lorenz
>>
>> P.S.: I decided to create a minimal example of how i use it right now. Maybe
>> it helps...
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
>> initial="enter_pin">
>>
>> <state id="enter_pin">
>> <invoke targettype="java" src="EnterPin" />
>> <transition event="fail" target="pin_failed" />
>> <transition event="succ" target="pin_succeeded" />
>> </state>
>>
>> <state id="pin_failed">
>> <invoke targettype="java" src="HandlePinFailed" />
>> <transition event="finish" target="end" />
>> <transition event="retry" target="enter_pin" />
>> </state>
>>
>> <state id="pin_succeeded">
>> <invoke targettype="java" src="HandlePinSucceeded" />
>> <transition event="finish" target="end" />
>> </state>
>>
>> <state id="end" final="true" />
>>
>> </scxml>
>>
>> ---------------------
>>
>> SCXML scxml =
>> SCXMLParser.parse(ClassLoader.getSystemResource("sc.xml"), new
>> SimpleErrorHandler());
>> SCXMLExecutor executor = new SCXMLExecutor(new JexlEvaluator(), new
>> SimpleDispatcher(), new SimpleErrorReporter());
>> executor.setRootContext(new JexlContext(new HashMap()));
>> executor.setStateMachine(scxml);
>> // ReflectiveInvoker calls "EnterPin", "HandlePinFailed", etc. by reflection
>> executor.registerInvokerClass("java", ReflectiveInvoker.class);
>> executor.go();
>>
>> ---------------------
>>
>> Now the most likely completely wrong usage:
>>
> <snip/>
>
> Likely, yes. See note at bottom of interface Javadocs:
>
> http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/invoke/Invoker.html
>
> -Rahul
>
>
>
>> public class EnterPin {
>> public void handle(SCInstance sc) {
>> ...
>> if (success) {
>> sc.getExecutor().triggerEvent(new TriggerEvent("succ",
>> TriggerEvent.SIGNAL_EVENT));
>> }
>> else {
>> sc.getExecutor().triggerEvent(new TriggerEvent("fail",
>> TriggerEvent.SIGNAL_EVENT));
>> }
>> }
>> }
>>
>>
>>> On Fri, Sep 24, 2010 at 11:34 AM, Lorenz Schumann | Sysvision GmbH
>>> <lo...@sysvision.de> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> i am using Commons SCXML for the first time and am overall new to the
>>>> Statechart paradigm.
>>>> But i am working on a software where a statemachine is needed and the
>>>> first
>>>> choice fell on commons.
>>>> So much for the introduction.
>>>>
>>>> Now what we discovered is that when you navigate from state to state via
>>>> triggering events there is a recursion that makes the method-stack higher
>>>> and higher and will at some point throw an StackOverflowError.
>>>> This is what the important part of a stacktrace looks like:
>>>>
>>>> at
>>>>
>>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>>>> at
>>>>
>>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>>>> at
>>>>
>>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>>>> at MyInvoker.invoke(MyInvoker.java:23)
>>>> at
>>>>
>>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>>>> at
>>>>
>>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>>>> at
>>>>
>>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>>>> at MyInvoker.invoke(MyInvoker.java:23)
>>>> at
>>>>
>>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>>>> at
>>>>
>>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>>>> at
>>>>
>>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>>>> at MyInvoker.invoke(MyInvoker.java:23)
>>>>
>>>> Are we using it as it is meant to be? Is there a way that the execution
>>>> of
>>>> states is not beeing stacked?
>>>>
>>>>
>>>
>>> <snip/>
>>>
>>> The invoke paradigm is broadly about asynchronously initiating and
>>> interacting with external processes. From the trace it looks like your
>>> invoker may be synchronously triggering an event on the state machine
>>> (which may be initiating the invoke again and so on ad infinitum).
>>> Instead, invoke should simply initiate external processing
>>> asynchronously and then trigger an event back when the processing is
>>> done (or when it fails).
>>>
>>> Some background on usage is here [1].
>>>
>>> If what you are trying to do can be modeled as sending events to
>>> existing external processes, you can take a look at<send> and the
>>> EventDispatcher instead.
>>>
>>> If what you are trying to do can be modeled as inherently synchronous
>>> executable content within the state machine's<onentry>,<onexit> or
>>> <transitions>, then you can have a look a custom actions [2] instead.
>>>
>>> -Rahul
>>>
>>> [1] http://commons.apache.org/scxml/guide/using-commons-scxml.html
>>> [2] http://commons.apache.org/scxml/guide/custom-actions.html
>>>
>>>
>>>
>>>
>>>>
>>>> Help is much appreciated.
>>>>
>>>> Lorenz
>>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] Too many state navigation causes StackOverflowException
Posted by Rahul Akolkar <ra...@gmail.com>.
On Mon, Sep 27, 2010 at 6:40 AM, Lorenz Schumann | Sysvision GmbH
<lo...@sysvision.de> wrote:
> Hi Rahul,
>
> i took over a project in development and took the implementation as the
> correct way to do it.
> But after i read your response (thank you very much by the way!) i re-read
> everything in the documentation.
>
> I want to control a phone application with what scxml can offer me.
> But when i look at the stopwatch example i see a huge difference to our
> approach: When controlling a stopwatch the states change on user action
> (mostly). The user interface sends the events to the statemachine.
> But in our phone application the states change depending on what happens
> inside the invoked code. So we trigger the events inside the invoked code.
> I know there is some fraction of the puzzle i am missing and i cannot see
> how to fire the events from outside to control the statemachine.
>
<snip/>
I think part of it is that you have started with one of the most
flexible and thereby, harder constructs i.e. invoke to work with. If
the code that you are invoking isn't long running, then you are better
off using constructs that allow for easier synchronous usage for
triggering events.
> I also couldn't find any helpful examples. Anything that helps is
> appreciated!
>
<snap/>
There is an example (related to mobile apps) linked from the home
page, see "Who is using it?" section:
http://commons.apache.org/scxml/
Some details here, code is invoked using custom actions (not using invoke):
http://mymobileweb.morfeo-project.org/mymobileweb/mymw-tech/scxml
I pointed to the guide in the previous email, which has more on custom actions.
> Thanks in advance!
>
> Lorenz
>
> P.S.: I decided to create a minimal example of how i use it right now. Maybe
> it helps...
>
> <?xml version="1.0" encoding="UTF-8"?>
> <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
> initial="enter_pin">
>
> <state id="enter_pin">
> <invoke targettype="java" src="EnterPin" />
> <transition event="fail" target="pin_failed" />
> <transition event="succ" target="pin_succeeded" />
> </state>
>
> <state id="pin_failed">
> <invoke targettype="java" src="HandlePinFailed" />
> <transition event="finish" target="end" />
> <transition event="retry" target="enter_pin" />
> </state>
>
> <state id="pin_succeeded">
> <invoke targettype="java" src="HandlePinSucceeded" />
> <transition event="finish" target="end" />
> </state>
>
> <state id="end" final="true" />
>
> </scxml>
>
> ---------------------
>
> SCXML scxml =
> SCXMLParser.parse(ClassLoader.getSystemResource("sc.xml"), new
> SimpleErrorHandler());
> SCXMLExecutor executor = new SCXMLExecutor(new JexlEvaluator(), new
> SimpleDispatcher(), new SimpleErrorReporter());
> executor.setRootContext(new JexlContext(new HashMap()));
> executor.setStateMachine(scxml);
> // ReflectiveInvoker calls "EnterPin", "HandlePinFailed", etc. by reflection
> executor.registerInvokerClass("java", ReflectiveInvoker.class);
> executor.go();
>
> ---------------------
>
> Now the most likely completely wrong usage:
>
<snip/>
Likely, yes. See note at bottom of interface Javadocs:
http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/invoke/Invoker.html
-Rahul
> public class EnterPin {
> public void handle(SCInstance sc) {
> ...
> if (success) {
> sc.getExecutor().triggerEvent(new TriggerEvent("succ",
> TriggerEvent.SIGNAL_EVENT));
> }
> else {
> sc.getExecutor().triggerEvent(new TriggerEvent("fail",
> TriggerEvent.SIGNAL_EVENT));
> }
> }
> }
>
>
>> On Fri, Sep 24, 2010 at 11:34 AM, Lorenz Schumann | Sysvision GmbH
>> <lo...@sysvision.de> wrote:
>>
>>>
>>> Hi,
>>>
>>> i am using Commons SCXML for the first time and am overall new to the
>>> Statechart paradigm.
>>> But i am working on a software where a statemachine is needed and the
>>> first
>>> choice fell on commons.
>>> So much for the introduction.
>>>
>>> Now what we discovered is that when you navigate from state to state via
>>> triggering events there is a recursion that makes the method-stack higher
>>> and higher and will at some point throw an StackOverflowError.
>>> This is what the important part of a stacktrace looks like:
>>>
>>> at
>>>
>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>>> at
>>>
>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>>> at
>>>
>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>>> at MyInvoker.invoke(MyInvoker.java:23)
>>> at
>>>
>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>>> at
>>>
>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>>> at
>>>
>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>>> at MyInvoker.invoke(MyInvoker.java:23)
>>> at
>>>
>>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>>> at
>>>
>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>>> at
>>>
>>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>>> at MyInvoker.invoke(MyInvoker.java:23)
>>>
>>> Are we using it as it is meant to be? Is there a way that the execution
>>> of
>>> states is not beeing stacked?
>>>
>>>
>>
>> <snip/>
>>
>> The invoke paradigm is broadly about asynchronously initiating and
>> interacting with external processes. From the trace it looks like your
>> invoker may be synchronously triggering an event on the state machine
>> (which may be initiating the invoke again and so on ad infinitum).
>> Instead, invoke should simply initiate external processing
>> asynchronously and then trigger an event back when the processing is
>> done (or when it fails).
>>
>> Some background on usage is here [1].
>>
>> If what you are trying to do can be modeled as sending events to
>> existing external processes, you can take a look at<send> and the
>> EventDispatcher instead.
>>
>> If what you are trying to do can be modeled as inherently synchronous
>> executable content within the state machine's<onentry>,<onexit> or
>> <transitions>, then you can have a look a custom actions [2] instead.
>>
>> -Rahul
>>
>> [1] http://commons.apache.org/scxml/guide/using-commons-scxml.html
>> [2] http://commons.apache.org/scxml/guide/custom-actions.html
>>
>>
>>
>>
>>>
>>> Help is much appreciated.
>>>
>>> Lorenz
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] Too many state navigation causes StackOverflowException
Posted by Lorenz Schumann | Sysvision GmbH <lo...@sysvision.de>.
Hi Rahul,
i took over a project in development and took the implementation as the
correct way to do it.
But after i read your response (thank you very much by the way!) i
re-read everything in the documentation.
I want to control a phone application with what scxml can offer me.
But when i look at the stopwatch example i see a huge difference to our
approach: When controlling a stopwatch the states change on user action
(mostly). The user interface sends the events to the statemachine.
But in our phone application the states change depending on what happens
inside the invoked code. So we trigger the events inside the invoked code.
I know there is some fraction of the puzzle i am missing and i cannot
see how to fire the events from outside to control the statemachine.
I also couldn't find any helpful examples. Anything that helps is
appreciated!
Thanks in advance!
Lorenz
P.S.: I decided to create a minimal example of how i use it right now.
Maybe it helps...
<?xml version="1.0" encoding="UTF-8"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
initial="enter_pin">
<state id="enter_pin">
<invoke targettype="java" src="EnterPin" />
<transition event="fail" target="pin_failed" />
<transition event="succ" target="pin_succeeded" />
</state>
<state id="pin_failed">
<invoke targettype="java" src="HandlePinFailed" />
<transition event="finish" target="end" />
<transition event="retry" target="enter_pin" />
</state>
<state id="pin_succeeded">
<invoke targettype="java" src="HandlePinSucceeded" />
<transition event="finish" target="end" />
</state>
<state id="end" final="true" />
</scxml>
---------------------
SCXML scxml =
SCXMLParser.parse(ClassLoader.getSystemResource("sc.xml"), new
SimpleErrorHandler());
SCXMLExecutor executor = new SCXMLExecutor(new JexlEvaluator(),
new SimpleDispatcher(), new SimpleErrorReporter());
executor.setRootContext(new JexlContext(new HashMap()));
executor.setStateMachine(scxml);
// ReflectiveInvoker calls "EnterPin", "HandlePinFailed", etc. by reflection
executor.registerInvokerClass("java", ReflectiveInvoker.class);
executor.go();
---------------------
Now the most likely completely wrong usage:
public class EnterPin {
public void handle(SCInstance sc) {
...
if (success) {
sc.getExecutor().triggerEvent(new TriggerEvent("succ",
TriggerEvent.SIGNAL_EVENT));
}
else {
sc.getExecutor().triggerEvent(new TriggerEvent("fail",
TriggerEvent.SIGNAL_EVENT));
}
}
}
> On Fri, Sep 24, 2010 at 11:34 AM, Lorenz Schumann | Sysvision GmbH
> <lo...@sysvision.de> wrote:
>
>> Hi,
>>
>> i am using Commons SCXML for the first time and am overall new to the
>> Statechart paradigm.
>> But i am working on a software where a statemachine is needed and the first
>> choice fell on commons.
>> So much for the introduction.
>>
>> Now what we discovered is that when you navigate from state to state via
>> triggering events there is a recursion that makes the method-stack higher
>> and higher and will at some point throw an StackOverflowError.
>> This is what the important part of a stacktrace looks like:
>>
>> at
>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>> at
>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>> at
>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>> at MyInvoker.invoke(MyInvoker.java:23)
>> at
>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>> at
>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>> at
>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>> at MyInvoker.invoke(MyInvoker.java:23)
>> at
>> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
>> at
>> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
>> at
>> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
>> at MyInvoker.invoke(MyInvoker.java:23)
>>
>> Are we using it as it is meant to be? Is there a way that the execution of
>> states is not beeing stacked?
>>
>>
> <snip/>
>
> The invoke paradigm is broadly about asynchronously initiating and
> interacting with external processes. From the trace it looks like your
> invoker may be synchronously triggering an event on the state machine
> (which may be initiating the invoke again and so on ad infinitum).
> Instead, invoke should simply initiate external processing
> asynchronously and then trigger an event back when the processing is
> done (or when it fails).
>
> Some background on usage is here [1].
>
> If what you are trying to do can be modeled as sending events to
> existing external processes, you can take a look at<send> and the
> EventDispatcher instead.
>
> If what you are trying to do can be modeled as inherently synchronous
> executable content within the state machine's<onentry>,<onexit> or
> <transitions>, then you can have a look a custom actions [2] instead.
>
> -Rahul
>
> [1] http://commons.apache.org/scxml/guide/using-commons-scxml.html
> [2] http://commons.apache.org/scxml/guide/custom-actions.html
>
>
>
>
>> Help is much appreciated.
>>
>> Lorenz
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
--
Lorenz Schumann
lorenz.schumann@sysvision.de
SYSVISION GmbH
Schauenburgerstraße 6
20095 Hamburg
Germany
Tel +49 40 4111114-0
Fax +49 40 4111114-99
http://www.sysvision.de
Eingetragen unter HRB 89175 beim Amtsgericht Hamburg
Geschäftsführer: Daniel Hanelt
Sitz: Hamburg
USt-IdNr. DE 232 606 746
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [scxml] Too many state navigation causes StackOverflowException
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Sep 24, 2010 at 11:34 AM, Lorenz Schumann | Sysvision GmbH
<lo...@sysvision.de> wrote:
> Hi,
>
> i am using Commons SCXML for the first time and am overall new to the
> Statechart paradigm.
> But i am working on a software where a statemachine is needed and the first
> choice fell on commons.
> So much for the introduction.
>
> Now what we discovered is that when you navigate from state to state via
> triggering events there is a recursion that makes the method-stack higher
> and higher and will at some point throw an StackOverflowError.
> This is what the important part of a stacktrace looks like:
>
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
> at MyInvoker.invoke(MyInvoker.java:23)
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
> at MyInvoker.invoke(MyInvoker.java:23)
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.initiateInvokes(SCXMLSemanticsImpl.java:847)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:142)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:160)
> at MyInvoker.invoke(MyInvoker.java:23)
>
> Are we using it as it is meant to be? Is there a way that the execution of
> states is not beeing stacked?
>
<snip/>
The invoke paradigm is broadly about asynchronously initiating and
interacting with external processes. From the trace it looks like your
invoker may be synchronously triggering an event on the state machine
(which may be initiating the invoke again and so on ad infinitum).
Instead, invoke should simply initiate external processing
asynchronously and then trigger an event back when the processing is
done (or when it fails).
Some background on usage is here [1].
If what you are trying to do can be modeled as sending events to
existing external processes, you can take a look at <send> and the
EventDispatcher instead.
If what you are trying to do can be modeled as inherently synchronous
executable content within the state machine's <onentry>, <onexit> or
<transitions>, then you can have a look a custom actions [2] instead.
-Rahul
[1] http://commons.apache.org/scxml/guide/using-commons-scxml.html
[2] http://commons.apache.org/scxml/guide/custom-actions.html
> Help is much appreciated.
>
> Lorenz
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org