InfoQ Homepage Presentations Real World Akka Recipes
Real World Akka Recipes
41:55
Summary
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.
Bio
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.
About the conference
Last year was sci-fi themed around The Hitchikers Guide to the Galaxy and the magical ’42’ number. This year we go for charm and a rich history with the Tapis Rouge salons.
May 01, 2014
-
Related Sponsored Content
-
Related Sponsor
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
Community comments
nice presentation of Akka
by nicolae caralicea,
Interesting, BUT
by Rüdiger Möller,
What's wrong with ACK?
by Simone Scarduzio,
Re: What's wrong with ACK?
by Rüdiger Möller,
nice presentation of Akka
by nicolae caralicea,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think that Akka is trying to solve too many things, so all the introduced design patterns and conventions are really nice and useful, but kind of overwhelming. it kind of slips into the same trap like EJB did before.
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.
Interesting, BUT
by Rüdiger Möller,
Your message is awaiting moderation. Thank you for participating in the discussion.
Imo they really should dig into NAK algorithm's as used in brokerless messaging. This way it is much cheaper to keep guarantee levels high without paying the ACK penalty. Without guarantees, application logic becomes much more complex and expensive, so you really want to shield the application layer from dealing with low level failure.
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?
by Simone Scarduzio,
Your message is awaiting moderation. Thank you for participating in the discussion.
He's all against ACK as a concept, but I don't think he understood what ACK means in messaging.
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"
Re: What's wrong with ACK?
by Rüdiger Möller,
Your message is awaiting moderation. Thank you for participating in the discussion.
"He's all against ACK as a concept, but I don't think he understood what ACK means in messaging."
You bet. Problem with ack is that it has a tendency to couple latency + throughput. One can get around this by increasing the window of accepted unacked messages (TCP alike), but best avoid ack wherever possible.
Its completely meaningless what semantic you put on the ACK. Its just better to "talk back" only in case something goes wrong instead of talking back to indicate things are succesful.