Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of rahul.akolkar@gmail.com
 designates 66.249.82.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=uTe1+Dts19k3LbdJMHyXE91/qsU4NQvPT2u59STt3FzVYK2o6/zgYSAUXxELfcrCe9nUVLo9da6w87t8Xx49EwuNAwyFxm7qFcjzH8e2CpLBF/c6daB9kE6z4eef09aPhi/JEB93rCQHRvzDrAXSQ9XgLp5xEzuEOv/FUZxi27w=
Message-ID: <ce1f2ea80511181051i5962f283h8af50c2d7b74397e@mail.gmail.com>
Date: Fri, 18 Nov 2005 13:51:32 -0500
From: Rahul Akolkar <rahul.akolkar@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [scxml] processing multiple events
In-Reply-To: <CDB88C76D4D72244973F442A5305F0F9208538@BOS1EXCH1.aspect.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <CDB88C76D4D72244973F442A5305F0F9208538@BOS1EXCH1.aspect.com>

On 11/18/05, Barnett, James <James.Barnett@aspect.com> wrote:
> I'm puzzled by the behavior of the scxml engine when I enter multiple eve=
nts (separated by spaces) at one time.  For example, when running the Stand=
alone version with test script transitions-01.xml, and in state 'ten', I wo=
uld expect to be able to enter events 'ten.done twenty_one.done twenty_two.=
done' and have the machine process all of them and go to state 'thirty'.  H=
owever, the system only takes the first transition, to state twenty/twenty_=
one.
>
<snip/>

Jim - Thanks for asking.

The space separated list is the list of events received between the
last trigger and the current one (this is the asynchronous time model
for state charts, where the engine reacts whenever an external event
is received -- as against the synchronous model where one step is
executed per unit time/clock tick). In fact, this does not imply any
temporal associations between the events being fired based on the
sequence in which they appear in the space separated list. Moreover,
all the events in the space separated list operate over the set of
candidate transitions that result from the ancestor closure of the
states that were active when the trigger was received i.e. all events
in a space separated list operate over the *same* ancestor closure.

The correct way to imply the temporal sequence that you refer to for
this SCXML example [1], therefore, is to fire events separately as
"ten.done", "twenty_one.done" and "twenty_two.done", in that order,
rather than a space separated list.

Note this does not mean the engine disregards multiple events when
fired at a time. You can verify that multiple events are accounted for
by specifying this list "foo.bar ten.done bar.foo" when in state
"ten", and observing that the appropriate transition for event
"ten.done" is indeed followed. A better example might be the trigger
"thirty_one_child_one.done thirty_two_child_one.done
thirty_three_child_one.done" right after entering the parallel and
noting that *each* of the orthogonal states follow their transitions.


> Looking at the code, I think that there is a  problem in triggerEvents in=
 SCXMLExecutor.java.  The method consists of a do loop, with each iteration=
 through the loop processing a single event.  However at the bottom of the =
loop, we have:
<snap/>

Each iteration is not processing one event, rather all events in that
trigger. Note that the constructor for Step takes the entire list of
events, not just the first one.

>
>            if (superStep) {
>               evs.clear();
>            }
>        } while(superStep && currentStatus.getEvents().size() > 0);
>
> so if 'superStep' is true, the event list is cleared (via 'evs.clear').  =
However, if 'superStep' is false, the 'while' condition will cause the loop=
 to exit after the first iteration.  So multiple events will never get proc=
essed.  I find that if I comment out both conditions mentioning superStep, =
the multiple events do get processed and the system transitions to state 't=
hirty'.
<snip/>

The superStep concept, and that bit of code, is orthogonal to the
space separated event list question you ask above. That bit of code
merely ensures that if the external triggers have caused any internal
events fired by the SCXML engine to be enqueued for processing, the
external trigger list be cleared so the external triggers are not
considered to have been "fired" once again when the engine takes a
stab at processing the internal events.

Ofcourse:
a) One only needs to continue iterating if the engine is processing
triggers as a superstep, and
b) One needs to continue iterating until the state machine reaches a
"stable" configuration, whereby all internal events have been
processed and the event queue has been exhausted.


>
> These complications may arise from the semantics of superStep and its int=
eraction with the Standalone environment.  The simplest change would be to =
change the upper condition to 'if (! superStep)...', but I would think that=
 in that case the events should not be thrown away, but rather left in the =
queue for further processing.
>
<snap/>

Indeed, if events were "thrown away" that'd lead to extremely
undesirable behavior. But, as pointed above, that is not the case.


> Or am I completely off base?
>
> - Jim
> P.S. I have been able to compile the code, thanks to the previous pointer=
s to the commons-build area.  Many thanks.
>
<snip/>

Thanks for the nudge :-) In addition, if you update your local SCXML
root from the Commons Sandbox repository, you won't need commons-build
anymore. I committed the related changes yesterday, and I also created
a "Building Commons SCXML" page [2].

-Rahul

[1] http://svn.apache.org/repos/asf/jakarta/commons/sandbox/scxml/trunk/src=
/test/java/org/apache/commons/scxml/transitions-01.xml
[2] http://jakarta.apache.org/commons/sandbox/scxml/building.html

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