commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elam Birnbaum \(ebirnbau\)" <ebirn...@cisco.com>
Subject RE: [SCXML] Weird behavior with invoke
Date Tue, 06 Feb 2007 15:53:05 GMT
Rahul,

Thanks for the response. I think I understand what you are saying but I
need to make sure if I got it so will paraphrase below (with some more
questions). Please let me know if this is correct.

> This (turning around and triggering an event on the state 
> machine) is a no-no based on the following:
> 
>  * Once a state machine receives external stimulus (as one or 
> more events), it must complete processing before it can reach 
> a stable state and begin to process others stimuli. As a 
> corollary, developer responsibility is in not interrupting a 
> state machine while it is processing external event(s).
>
>  * Commons SCXML uses JDK 1.4 and synchronized triggerEvent() 
> method(s). If the owning thread requests (such as in the 
> above example), Java will grant it the reentrant lock. Things 
> may seem fine here, but we've broken the first principle 
> (above bullet).

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.

>  * <invoke> semantics work best when there is asynchronous 
> interaction. There shouldn't be any processing (of 
> significance) in any of the Invoker methods (invoke, 
> parentEvents, cancel), just the initiation of the processing 
> which will asynchronously continue to communicate with the 
> state machine as needed.

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 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?

I guess want to understand better what the consequences would be if I
did all my work in the invoke and parentEvents methods without spawning
threads except for actually triggering the events. I would prefer to
keep doing all my work in these methods and only spawn a thread for
triggering events. If I could limit the spawned threads to just
triggering events I could keep my design simple because the lifetime of
that thread would be very small. If I had to do a lot of processing in
those threads, then I would have to be more careful in the design to
avoid using too many threads at once (in other words thread pools) as my
system can involve hundreds if not thousands of simultaneous state
engine instances. 

> I suspect if you make the change above, these will generally 
> work as expected.

Yes, I saw that once I changed the code to trigger the events in
separate threads, the parentEvents method was triggered only for state
"step2" and not for the other state. However the process of triggering
an event while visiting the state "step2" still caused the cancel method
to be called.

> Could you please create an issue in JIRA [1] about the cancel 
> method in context of the invoke.done event? That'll ensure we 
> review it before the next release. Thanks.

Will do.

> Finally, as mentioned on the Commons SCXML home page, the 
> <invoke> bits are being worked out (in the W3C Working Group, 
> the draft lists a few things as TBD), so the implementation 
> also will need possible changes and/or improvements related 
> to the processing of <invoke> (both semantics and syntax, 
> such as event names) in future releases.

Ok, good to know. I'll stick with the invoke functionality because now
that I will use separate threads for triggering the events the only
issue I would need to work around is the cancel, which is not a big deal
for me.

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. 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.

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

Thanks again,

Elam Birnbaum

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message