commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorenz Schumann | Sysvision GmbH <lorenz.schum...@sysvision.de>
Subject Re: [scxml] Too many state navigation causes StackOverflowException
Date Mon, 27 Sep 2010 10:40:26 GMT
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
> <lorenz.schumann@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


Mime
View raw message