OnTransitioned handler gets state chnages in reverse order

[mabra]

Hi All !

I am having a problem with the order, the OnTransistioned method gives me.

I am wrapping the statemachine in a class and there is an Init method, which is called from ouside. This creates
a new thread and calls a ping method [the OnEntry for the inital state is not working]. The ping method fires the
one or the other trigger, where OnEntry methods are called. I have ReachableOnEntry and UnreachableOnEntry.
In this method, I call ping again and this will fire a trigger and this continues, until the state disabled is reached
or the reachable state is reached. This is completely working as expected !

The statemachine's fire method is wrapped by my class, because it also called from outside. In this methods
wrapper, I log the current state and the incoming trigger. Additionally, I have a OnTransistioned method, which
logs source and destination of the state.

What I am seeing in the log, is completely horror: My Fire wrapper logs the statechanges in the order, I am
expecting from my workflow and exactly, when it happens. The OnTransioned handler, starts logging, of the
thread comes to its end and then the transitions are given in opposite order!!!

This excerpt from the logs shows it:

08 21:51:42.051;11;TRACE;SM.ASM.hexe;Fire;226;from: Init: Will process trigger: PingFail
08 21:51:44.362;11;TRACE;SM.ASM.hexe;Fire;226;from: Unreachable: Will process trigger: PingFail
08 21:51:46.661;11;TRACE;SM.ASM.hexe;Fire;226;from: Unreachable: Will process trigger: PingFail
08 21:51:48.967;11;TRACE;SM.ASM.hexe;Fire;226;from: Unreachable: Will process trigger: PingFail
08 21:51:48.970;11;TRACE;SM.ASM.hexe;Fire;226;from: Unreachable: Will process trigger: Disabled

08 21:51:48.975;11;TRACE;SM.ASM.hexe;OnChange;196;Change from: Unreachable, to: Disabled
08 21:51:48.983;11;TRACE;SM.ASM.hexe;OnChange;196;Change from: Unreachable, to: Unreachable
08 21:51:48.996;11;TRACE;SM.ASM.hexe;OnChange;196;Change from: Unreachable, to: Unreachable
08 21:51:49.008;11;TRACE;SM.ASM.hexe;OnChange;196;Change from: Unreachable, to: Unreachable
08 21:51:49.016;11;TRACE;SM.ASM.hexe;OnChange;196;Change from: Init, to: Unreachable

I dont understand this. I could show my State and Trigger definitions and the statemachine too, if this
helps. I am currently seeing, that the OnTransitioned method is completely useless for me and I have
to build my on event based on my Fire wrapper [where is everything ok and in the right oder].

Any help would be really very great! I cannot just make a short repro.

Thanks so far and
best regards,

++mabra

[Grant BlahaErath]

Hi Mabra,

It looks fine to me, but I suspect you haven't composed your state machine in a way that works with the library.  Just to start, I'd say in the dozens of ways I've used Stateless I never used OnTransitioned.  

It's been a year since I've used the library, but the approach I used was to create a state diagram on paper (or using a tool like Visio).  By doing so, you can prove your machine correct and you won't miss any triggers, transitions or states.  When working with stateless, automata theory is a great help in understanding its design.

I would then translate the diagram into Stateless.  Every box in the diagram became a State.  The lines to each to each state are implied by the Permit relationships.     

I created a Trigger for every external event that would trigger a transition.    I would then apply those to the Permit definitions in a way that matched my state diagram.  

OnExit/OnEntry are used for side effects.  If a state change is a proxy for a lot of activity, then implement that activity on the Entry functions.  I usually had my Entry functions post messages to a queue so a work thread would run the side effect.  When a state transition was gated on the completion of work, I'd have the worker post a completion message.  The completion message would then cause a trigger to fire on the state machine.

I've used it to great affect for UX behavior, cryptographic protocols and server/client interactions.  Whenever If/Then/Else/Switch/Case gets to complicated, Stateless was a great abstraction to keep it all together.

-g 

--
 
---
You received this message because you are subscribed to the Google Groups "Stateless .NET State Machine Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnet-state-machine-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[mabra]

Hello !

Thanks Grant ! Initially, I have had problems to understand the usage of stateless, especially,
everything is async for me.

I am usually do my state-thinking-defining in powerpoint. Such a process make the things
more clear to yourself [I saw the visual statedesigner for stateless on codeplex, but it's
currently not that powerful].

Yesterday, I made a big session in VS and found the reason: I am calling FIRE in the
OnEntry methods, so I am processing everythingrecursively until the final stage is reached.
Luckily, the states are right and have a FINITE state ;-)
[Otherwise, I would have had an endless recursion ;-) ]

The problem is, that I do not have a separate thread to process. The app manages
the connections so hundreds of computers in a resource save manner. The App
loops over a list of computer objects and call their init method. In that init method,
the computers stateengine will be initialized and the stateengines init method will
be called on a separate therad, which calls OnEntry, fire, onEntry, fire ...

The background is, that I have a ProducerConsumer model with a small reserved
number of threads. What I reworked now is, to span a new workitem to one of the
threads and that will call the work method of the stateengine. This may change
state, but put the work method back onto the ProducerConsumer pool. The bad
thing now is, that I have a switch/case block in the work method deciding on the
current state. This is a little unexpected [I made statemachines until now with
one concrete class per state]. But now, this works well !

I had an initial help call here, becuase I don't understand and the phone demo
is just too simple ;-)

Thanks for the help!

Best regards,

++mabra

To unsubscribe from this group and stop receiving emails from it, send an email to dotnet-state-machine-framework+unsubscribe@googlegroups.com.

[Grant BlahaErath]

Mabra, that is great to read.  

In my last email I almost wrote:

"Do not call Fire inside of OnEntry/OnExit"

-- or --

"Do not start a second transition before the first transition has finished." 

But you can do it if you know what the side-effect is.  You just don't want to fill up your stack or have code execute after "Fire".  When I first used Stateless I wrote code that worked fine for the first few hours until the stack filled up.   :-)   

Since then I use some kind of while loop (or a queue and thread pool for async) to execute the stateless "Fire" message.   Then your transitions fully complete before the next transition starts.  

I have a theory about the phone demo that, I presume, Nicholas wrote.

1. Smart engineers really know what FSM is used for.

2. Smart .NET engineers find Stateless and start using it.

3. Smart engineers are always in demand and never have the time they need.

Therefore:

4. Smart engineers never get to finish the demos and docs on their side projects. :-)

It's a problem we all have to deal with.   

-g

To unsubscribe from this group and stop receiving emails from it, send an email to dotnet-state-machine-...@googlegroups.com.

[mabra]

[mabra]

Hi !

I agree completely .... ;-)
Additionally, I am pretty sure, your hints started a silent bell
in my brain ;-)

br,

++mabra

[mabra]

Hi and Thanks !

I agree completely ... ;-)
Additionally, I assume, your hints triggered something like
a silent bell in my brain ... ;-)

br,

++mabra
[might be a re-post ?? Message did'nt appear ....google]