Jamie Allen describes three patterns using Akka actors: handling a lack of guaranteed delivery, distributing tasks to worker actors and implementing distributed workers in an Akka cluster.
Jamie Allen is the Director of Consulting for Typesafe, having worked in consulting since 1994 with top firms including Price Waterhouse and Chariot Solutions. Jamie has been coding in Scala and actor-based systems since 2009, and is the author of “Effective Akka” book from O’Reilly.
nice presentation of Akka
I liked the Erlang approach where you had just a few generic ones, and everything else would be based on them. A tradeoff should be found here, but this could be just a matter of taste.
I haven't played yet with Typesafe Activator (i'm not into embracing powerful frameworks that would hide the complexity from the developer - this might not be the case, though), but I think that it would be nice to see a demo showcasing the followings:
- defining your Akka cluster members
- going to your IDE and loading the generated project from where you could run and see the documented code. To me this is more important than using the Typesafe activator's UI, so Typesafe Activator would play the role of a bootstrap, only. From then on I would only use the IDE for the whole lifecycle of the project.
With NAK, retransmission is used to fix things behind the scenes. Only definitive message loss is reported to the application layer then.
Regarding Actors: if you look at Dart Isolates, Node.js, go lang, java kontraktor: They all use the same technical foundation like actors, however they promote a
more course grained way of composing those 'actors', even when using the same model from a technical perspective as the truth is: the less actors your system has, the easier to reason about, monitor and develop.
What's wrong with ACK?
Rather than "the message has been processed", it's more like "the responsibility of processing this message has successfully been deferred to the receiving system"