Akka, Thread Dispatchers, Agents Best Practice

Question

I've dabbled in Scala for a while, and have studied Akka from afar, and am finally plunging in. The FSM trait sealed the deal for me. What concerns me is that I may have conceived of how data would be shared inappropriately, and I may have conceived of the event processing loop incorrectly to match Akka best practices.

In my problem I have a central coordinator who will match incoming task requests to appropriate actors that are also Finite State Machines. I had originally assumed that onTransition would give not only the state name but also the state data.

I guess traditional data encapsulation would be the reason for not exposing that data to listeners. But for me, I have two uses for others to see that data.

The state data contains an underlying domain object whose properties are used to determine which actors are the best candidate to handle the job given it's requirements. Since job requirements are dynamic I am hesitant to have separate collections of the worker actors (though I'm not sure why that should give me pause).

The idea of querying all the separate actors who meet other preconditions and joining for all their replies feels inefficient or at least not idiomatic to Akka. I'll also need to display in the UI the current state and see no reason that should use the same event queue to view state.

Anyway, I was considering have the FSM update an agent, but since that's an actor itself, I'm not sure what that layer of indirection buys me, and it may make reasoning about the sequence of events much harder.

Fowler's Event Collaboration points me to sending the state data explicitly but I was hoping for an easier way to do this for all transitions that update the state data automatically.

I'm also having a hard time wrapping my head around the sequencing of event cascades, and whether I need to control that. Even if all my incoming external events come through a single actor, I'll want to process all internally generated events to all the other actors before handling the next external event. I was thinking of having the central coordinator use !! to wait for a response, but I'm concerned that if accidentally delete one exclamation point somewhere in the event chain that I'll lose that guarantee.

Solutions I'm considering to this problem include using priority events such that internal events are given a higher priority, using a single threaded dispatcher (maybe with work stealing?) for all the "internal" actors that is shared.

Are there best practices involved for what I'm trying to do, or am I trying to do the wrong thing :) ?

Answer 1

I'd recommend publishing the state changes to a bus where listeners can register for updates.