Composing 'receive'

[Derek Wyatt]

Howdie,

I was playing around with some complexity in my design.  There are a number of ways to slice this (most notably, having more Actors), but I decided to investigate this idea a bit.  I'm posting it here for people to look at but I don't know if it's worth continuing for myself at the moment.

The problem is that I have an Actor that has a couple of responsibilities.  It changes state on its main behaviour, but there's also an auxiliary algorithm in it that is also stateful.  For example, once someone asks it to do something, it should do that thing but ignore requests to do it again until it's finished the first time through it.  Just a quick flip-flop thing...

Composing the receive method with 'orElse' doesn't scale so well as the permutations go up... Assuming that the different parts don't have a domain overlap (i.e. they don't override one another) then order of composition doesn't matter.  Thus, we can use something like I've cooked up here:

https://gist.github.com/1855018

Like I said, it's just an experiment. :)

[rkuhn]

Hi Derek,

yes, that looks like an “orthogonal multi-FSM” (just made that up, I need to find that paper again which had all the definitions). There was another single-track composition trait proposed earlier, which was even slimmer, and others will probably be cooked up as needed. We didn't include this in the distribution because it is so easy to roll your own, but it might make a good entry in a “cook-book”.

When certain releases are done and I begin getting bored I always thought I should come back to the FSM module and make it possible to have coupled state machines in the same actor, then also permitting overlapping event sets. It's just not easy to come up with a nice and consistent DSL for it.

Regards,

Roland

[Derek Wyatt]

It does seem to have some value… It's niche seems to be when spawning multiple Actors to hold the differing behaviour is more problematic and/or the mutable data required is shared between behaviours.

I am interested in the "easy to roll your own", though… I played with it for about 20 or 30 minutes and found the initialization of the composed beast to be a real pain in the ass. The 'receive' method is very difficult to compose initially. I can't find the right order / hook / whatever to get it to build properly - i.e. it's got nothing in it. The only way I could get it to work was to "become" the initial composition after construction (i.e. preStart()).

I wouldn't be surprised at all if I were missing something - I'm no scala god - but might it be a tad more difficult to roll your own these days than it was back in the 1.x days?

> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/GUUQLTEnOmMJ.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>

[rkuhn]

Hi Derek,

I see what you mean: the receive() method is called from the constructor of the Actor trait, i.e. before the constructor of the subclass has run. I need to think a little about it, but it looks like extracting receive() before someone is allowed to call become() is a necessary evil, which means that using become() is mandatory in these scenarios.

Regards,

Roland

[Bernd Johannes]

Hiho,

I experienced the same - I tried to have a dynamic receive() which acts on different "subreceives" based on the sender of the message (because I had the necessity to process the same message differently based on the sender of the message).

But I got stuck because of initialization order issues which I could not resolve.

So it was indeed the "become" call which came to the rescue. I think this is a point worth mentioning in the cookbook or docu because it's a terrible wast of time when you get caught by this for the first time.

But all in all akka (2.0 M4) rocks! I enjoy it very much.

Keep up the good work.

Greetings

Bernd

[rkuhn]

Am Samstag, 18. Februar 2012 12:59:30 UTC+1 schrieb Bernd:

Hiho,

I experienced the same - I tried to have a dynamic receive() which acts on different "subreceives" based on the sender of the message (because I had the necessity to process the same message differently based on the sender of the message).

But I got stuck because of initialization order issues which I could not resolve.

So it was indeed the "become" call which came to the rescue. I think this is a point worth mentioning in the cookbook or docu because it's a terrible wast of time when you get caught by this for the first time.

created a ticket so it’s not forgotten.
 

But all in all akka (2.0 M4) rocks! I enjoy it very much.

Keep up the good work.

Thanks! Keep on hAkking!

Regards,

Roland