FSM vs become/unbecome in Akka

Question

Akka provides two somewhat overlapping ways to manage actor states, Finite State Machines and unbecome/become. What are their respective benefits/drawbacks? When should one of t

Answer 1

FSM is a DSL that allows you to build more sophisticated, readable state machines than would be possible using the core actor API. You could potentially show the FSM code to a business person and they could validate the business rules.

The FSM DSL allows you to compose things together more cleanly. For example transitions allow you to factor out logic that would have to be duplicated across actor become behaviors. Also you can subscribe other actors to be notified of transitions which helps with decoupling and testing.

Also timers are integrated nicely into the DSL and things like cancellation are handled cleanly. Coding timeout messages using the scheduler has a number of gotchas.

The down side to FSM is that it's a DSL and a new syntax for other team members to digest. The up side is that it's a DSL and a much higher level abstraction. I think agilesteel's threshold of 2 states is a good one. But once you get past 2 states the benefits of FSM are really compelling.

Definitely read the FSM docs and the accompanying examples contrasting become and FSM.

One note re: "popping" a behavior using unbecome - the default behavior is to not use the behavior stacking. It is only relevant in a small number of use cases (ie, usually not state machines).