On Thursday, January 9, 2014 1:56:02 PM UTC+2, Tim Pigden wrote:
>
> 1. write your own fsm and embed it in an actor (it's not that hard. I
> wasted a quite a lot of time trying to bend the akka one to my purposes
> inappropriately before I realised this).
> 2. consider whether you are ever truly "active". After all you never had
> the opportunity to process messages in the active state. In which case
> shuffle the active transition processing into a separate method where you
> can access from either place. I'm not saying this is appropriate for you.
> 3. someone in scala-user suggested a self-message. Don't do that if
> there's a slightest change another message will arrive (or be in your input
> queue) otherwise it will be out of sequence. You might be able to
> circumvent this with some multi-actor explicit queue management but for me
> this was the first step in the slippery slope that led to wasted time and
> kept me away from realising that (1) was best for me.
>
Thanks Tim,
Yes, the actor should stay in Active, the transition from Waiting to
Expired being very infrequent, but it does happen.
I guess I'll write my own FSM :-)
>
> On Thursday, January 9, 2014 9:32:22 AM UTC, Alexandru Nedelcu wrote:
>>
>> Hi,
>>
>> I'm re-posting this from scala-user.
>>
>> I have a problem with FSM Actors in Akka. Say I have a bunch of states
>> and the transitions look something like this:
>>
>> Waiting -> Active -> Expired
>>
>> You can't get from Waiting to Expired directly. But when in "Waiting" I
>> still need to be able to send an "Expire" message to the actor, at which
>> point I need the actor to execute the transition changes for both (Waiting
>> -> Active) and for (Active -> Expired).
>>
>> So I basically want something like this (making stuff up):
>>
>>
>> when(Waiting) {
>> case Event(Expire, _) =>
>> goto(Active).andThen(Expired)
>> }
>>
>> onTransition {
>> case Waiting -> Active => /* activate */
>> case Active -> Expired => /* expiry */
>> }
>>
>> This is basically a non-deterministic finite automaton.
>>
>> Looking at the documentation and in the source-code, I don't believe this
>> is possible. It would have been great though, because the goto() on the
>> Expire event would make it perfectly clear that the actor first goes into
>> Active before being Expired. So what choices do I have?
>>
>> Thanks,
>>
>>
>>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.