commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [SCXML] Timers in SCXML
Date Wed, 15 Apr 2009 18:37:17 GMT
On Wed, Apr 15, 2009 at 11:02 AM, Linda Erlenhov
<linda.erlenhov@gmail.com> wrote:
> Hello
> Sorry to mass-spam email you, but I solved the problem myself after a food
> break and some more thinking.  The problem was the way I was trying to solve
> the data requests i asked about in another mail. So this is not a problem
> anymore, thank you!
>
<snip/>

This isn't remotely close to spam, in fact its quite useful to know
when issues are resolved so thanks for following up.

-Rahul



> //Linda
>
> On Wed, Apr 15, 2009 at 2:16 PM, Linda Erlenhov <linda.erlenhov@gmail.com>wrote:
>
>> Hello again.
>> I run the standalone test and it looks like the timers work fine there (An
>> infinit loop between the two states, the logs, except for those that was
>> nested as you pointed out, are printed one or two seconds apart as specified
>> in the scxml ), so now I´m a bit clueless with how to proceed, any idéas? Is
>> there anything I might have forgotten in my java files since it doesn´t work
>> there?
>>
>> best regards
>> //Linda
>>
>> On Tue, Apr 14, 2009 at 9:11 PM, Rahul Akolkar <rahul.akolkar@gmail.com>wrote:
>>
>>> On Tue, Apr 14, 2009 at 8:19 AM, Linda Erlenhov
>>> <linda.erlenhov@gmail.com> wrote:
>>> > Hello!
>>> >
>>> > This may be a stupid question but:
>>> > I have read through the code for the simple scheduler and I´m  not sure
>>> i
>>> > understand what happens.
>>> > We have written a simple scxml for a small statechart containing two
>>> states
>>> > with timers and used the simple scheduler as described in your previous
>>> > e-mail. As I understand the timers would make the machine just jump
>>> between
>>> > the two states. This doesn´t happen. Why?
>>> <snip/>
>>>
>>> The Commons SCXML version and the relevant driver (Java) code will
>>> help towards answering -- we know this works, so we'll need to know
>>> whats being done differently. Bear in mind that the timers execute as
>>> daemons.
>>>
>>> I suggest trying your example standalone [1] first, and we'll go from
>>> there.
>>>
>>> As an aside, in the markup below, <log> is nested in <send> which
>>> isn't legal, so the nested <log> will be ignored.
>>>
>>> -Rahul
>>>
>>> [1] http://commons.apache.org/scxml/guide/testing-standalone.html
>>>
>>>
>>>
>>> > ---------------------------
>>> > <scxml version="1.0" initialstate="167" xmlns:cs="
>>> > http://commons.apache.org/scxml" xmlns="http://www.w3.org/2005/07/scxml
>>> ">
>>> > <state id = "167">
>>> > <transition target="StateA"/>
>>> > </state>
>>> > <state id ="StateA">
>>> > <onentry>
>>> > <log label="Renegade" expr="'Entering state: A'"/>
>>> > <send sendid="1" event="'ToB'" delay="'1000ms'">
>>> > <log label="Renegade" expr="'Timer starting...'"/>
>>> > </send>
>>> > </onentry>
>>> > <transition event="ToB" target="StateB"/>
>>> > </state>
>>> > <state id="StateB">
>>> > <onentry>
>>> > <log label="Renegade" expr="'Entering state: B'"/>
>>> > <send sendid="2" event="'ToA'" delay="'2000ms'">
>>> > <log label="Renegade" expr="'Timer starting...'"/>
>>> > </send>
>>> > </onentry>
>>> > <transition event="ToA" target="StateA"/>
>>> > </state>
>>> > </scxml>
>>> > ---------------------
>>> >
>>> > The output when this is run is simply:
>>> > 2009-apr-14 13:08:57 org.apache.commons.scxml.model.Log execute
>>> > INFO: Renegade: Entering state: A
>>> > 2009-apr-14 13:08:57 org.apache.commons.scxml.env.SimpleScheduler send
>>> > INFO: send ( sendId: 1, target: null, targetType: scxml, event: ToB,
>>> params:
>>> > null, hints: null, delay: 1000)
>>> >
>>> > best regards
>>> > //Linda
>>> >
>>>

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


Mime
View raw message