On Fri, Sep 24, 2010 at 11:34 AM, Lorenz Schumann | Sysvision GmbH <lorenz.schum...@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-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
