commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] Weird behavior with invoke
Date Tue, 06 Feb 2007 20:10:58 GMT
On 2/6/07, Elam Birnbaum (ebirnbau) <> wrote:
> Ok, so let me see if I understand. You don't want to interrupt a state
> machine while it is working, but you don't really know when the state
> engine is working, which is why the concept of triggering events exists.
> The events are processed by the engine when it has time to do so. Now,
> the invoke, parentEvents, and cancel methods are all called by the state
> engine (and hence the thread that is executing the engine) and the
> engine blocks until these methods return. That means that when these
> methods themselves trigger events the state engine must handle them
> immediately  and would essentially give priority to those events and not
> the events that the state engine has queued up. Not only that, but the
> state engine will not register the ending of a state and the entrance of
> another because it is handling the events in-line, which explains why I
> saw so many parentEvents method calls.
> That is why you want to be triggering events asynchronously, as
> evidenced by the SimpleSCXMLInvoker class in the Commons SCXML project,
> which triggers events in an asynchronous manner via the AsynchTrigger
> class.

Mostly, yes. I'd add that its not the state machine engine (or any
part of the Commons SCXML code) giving priority to events triggered
synchronously within callbacks. Its already a deadlock (while it may
not manifest as such immediately), and also an attempt to
short-circuit any external event queues that the application may have
set up.

> Normally I would think that you would want the state engine to stop
> while the invoke process is running because that is what the state
> engine should be doing at the time

Sure, thats when the state machine "comes to rest". More often than
not, the time a state machine instance is processing events is going
to be a (small) fraction of its total lifetime.

> and the next state to visit will be
> determined by the events triggered by the invoke. Any parallel states
> would already be working in separate threads, so blocking in the invoke
> should not cause parallel states to block. So the only reason I can see
> for not wanting the invoke (and other methods) to take more than a
> trivial amount of time is because the state engine could have events
> waiting on it that would be prevented from being handled until the
> invoke method returned. The only event I could think of that would be
> triggered while the invoke method is being processed is the cancel
> event, which you would want to actually stop the invoke process. Are
> there any others?

Any application defined events (having parallel invoked processes,
sooner or later one will need some sort of IPC).

> A couple of final notes. Since I was seeing this issue because I was not
> triggering events in separate threads, I would recommend that Commons
> SCXML either improve how events are triggered or update the
> documentation regarding invoke to point out that fact as it is not
> readily apparent.

Or both, atleast the docs, i.e. we need a section in the user guide
[1] devoted to invoke. If you want to write up some of your
observations, either via the site sources [2] or the wiki [3], that'd
be great too.

> It would be great if the Commons SCXML
> SCXMLExecutor.triggerEvent and triggerEvents methods automatically
> spawned threads to actually trigger the events so that users won't have
> to worry about doing it themselves. To add flexibility, perhaps a
> setting in the SCXMLExecutor class could be exposed so the user can turn
> on or off whether events are triggered in separate threads.

Correct, its a trade-off between complexity in the library (and some
may say code smell with boolean flags) and developer discipline. We
definitely do not want to spawn threads without an option not to (when
it is deemed unnecessary, or inappropriate). Could be mitigated by

> I will look to see if Jira has an option for feature requests so I can
> put that in.

Sure, when you try to create a new issue, you can label it as a "Bug"
or "Improvement" or "Task" etc. (I think there are a couple of



> Thanks again,
> Elam Birnbaum

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message