[SCXML] Terminate/Halt SCXML state machine from external

[Ingmar Kliche <in...@googlemail.com>]

I need to terminate a state machine instance from external (i.e. not from
markup) to prevent it to process any further event. A SCXMLExecuter.reset()
is unfortunately more than a pure "reset", it is also a "go" (i.e. the
initial state is executed and therefore the state machine is again active).
How do I really _terminate_ a state machine, including all the clean up for
cancelling existing <invoke>'s etc.?

- Ingmar.

Re: [SCXML] Terminate/Halt SCXML state machine from external

[Rahul Akolkar <ra...@gmail.com>]

On 7/6/07, Ingmar Kliche <in...@googlemail.com> wrote:
> >
> >
> > > I think doing this without markup should generally be avoided since it
> > > makes the model incomplete. So, for example, an abrupt termination
> > > would be an event trigger that takes us to a particular <final>. I
> > > presume there is some reason you can't do it that way.
> >
> >
> > One major reason is that I don't want to rely on the author. I'd like to
> > be able to start a state machine and (under some circumstances) to terminate
> > it from outside - without requiring the author to provide a special
> > transition.
> >
> > Such support can probably be provided, but I am not too keen on it at
> > > the moment.
> > >
> > > -Rahul
> >
> >
> > Ingmar.
> >
>
>
> Wouldn't you actually have the same issue on <invoke>? How would you
> implement the cancel of an <invoke>? Once the parent state machine leaves
> the <invoke> state it is required to terminate the child state machine
> (assuming it is a state machine). How would you do this?
>
<snip/>

I think what is truly required is to send a 'Cancel' event, quoting:

"If the the invoking state machine takes a transition out of the state
containing the <invoke> before it receives the 'Done' event, it must
automatically send a 'Cancel' event to the invoked component to notify
it that it may stop its processing"

If this is not happening, then it should. But this is all that is
required. The state machine needs to watch for this 'Cancel' event and
terminate itself as it sees fit.

Both your usecases are IMO the failure of the author to completely
model the state machine. We could discuss whether this utopian view is
optimal, but I don't see any disconnect in things as they are.

-Rahul


> The SimpleSCXMLInvoker implementation does not reflect this - as I
> understand it. It saves "cancelled = true" and sends an invokeCancelResponse
> message back, but it does not really touch the child state machine, i.e. the
> state machine remains in the current state and may proceed internally
> meanwhile.
>
> Or am I missing something?
>
> - Ingmar.
>

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

Re: [SCXML] Terminate/Halt SCXML state machine from external

[Ingmar Kliche <in...@googlemail.com>]

>
>
> > I think doing this without markup should generally be avoided since it
> > makes the model incomplete. So, for example, an abrupt termination
> > would be an event trigger that takes us to a particular <final>. I
> > presume there is some reason you can't do it that way.
>
>
> One major reason is that I don't want to rely on the author. I'd like to
> be able to start a state machine and (under some circumstances) to terminate
> it from outside - without requiring the author to provide a special
> transition.
>
> Such support can probably be provided, but I am not too keen on it at
> > the moment.
> >
> > -Rahul
>
>
> Ingmar.
>


Wouldn't you actually have the same issue on <invoke>? How would you
implement the cancel of an <invoke>? Once the parent state machine leaves
the <invoke> state it is required to terminate the child state machine
(assuming it is a state machine). How would you do this?

The SimpleSCXMLInvoker implementation does not reflect this - as I
understand it. It saves "cancelled = true" and sends an invokeCancelResponse
message back, but it does not really touch the child state machine, i.e. the
state machine remains in the current state and may proceed internally
meanwhile.

Or am I missing something?

- Ingmar.

Re: [SCXML] Terminate/Halt SCXML state machine from external

[Ingmar Kliche <in...@googlemail.com>]

2007/7/6, Rahul Akolkar <ra...@gmail.com>:
>
>
> I think doing this without markup should generally be avoided since it
> makes the model incomplete. So, for example, an abrupt termination
> would be an event trigger that takes us to a particular <final>. I
> presume there is some reason you can't do it that way.


One major reason is that I don't want to rely on the author. I'd like to be
able to start a state machine and (under some circumstances) to terminate it
from outside - without requiring the author to provide a special transition.


Such support can probably be provided, but I am not too keen on it at
> the moment.
>
> -Rahul


Ingmar.

Re: [SCXML] Terminate/Halt SCXML state machine from external

[Rahul Akolkar <ra...@gmail.com>]

On 7/6/07, Ingmar Kliche <in...@googlemail.com> wrote:
> I need to terminate a state machine instance from external (i.e. not from
> markup) to prevent it to process any further event. A SCXMLExecuter.reset()
> is unfortunately more than a pure "reset", it is also a "go" (i.e. the
> initial state is executed and therefore the state machine is again active).
> How do I really _terminate_ a state machine, including all the clean up for
> cancelling existing <invoke>'s etc.?
>
<snip/>

I think doing this without markup should generally be avoided since it
makes the model incomplete. So, for example, an abrupt termination
would be an event trigger that takes us to a particular <final>. I
presume there is some reason you can't do it that way.

Such support can probably be provided, but I am not too keen on it at
the moment.

-Rahul


> - Ingmar.
>

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