What are the best use cases for Akka framework [closed]

java scala asynchronous akka

Closed. This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 8 years ago. Improve this question

I have heard lots of raving about Akka framework (Java/Scala service platform), but so far have not seen many actual examples of use cases it would be good for. So I would be interested in hearing about things developers have used it succesfully.

Only one limitation: please do not include case of writing a chat server. (why? since this has been overused as an example for lots of similar things)

Isn't it easier to start with the problem and find a solution for it, than having a solution and looking a problem to apply it on? My guess is that instead using RMI, Akka and its actors look much easier/simpler to write code for.

Yes, if I had specific problem to solve. I am not looking for an "excuse to use Akka" by any means, but I am interested in learning bit more. This may help solve future problems too, but mostly it's for on-going learning process.

There is related question but about applying AKKA for existing application + some use cases: stackoverflow.com/questions/16595685/…

Akka is a better solution over JMS or an MQ-style distributed messsage queue system. That's the best way to understand it for myself who was recently asking the exact same question: "I understand how to use it and see where I could use it, but I can't see where this would provide a real advantage". The core design assumptions behind Akka are much better than those behind JMS/MQ, specifically regarding process isolation, lock-less design, and retry/failure handling. Secondly, the API is much more elegant than JMS/MQ tools.

@user2684301 hmmh. I find that answer bit unfair, in apples-to-oranges way. MQs are (logically) simple building blocks that do much less than Akka, and I would not compare them side by side. But I guess if I read it as "compared to distributed systems built using JMS, written declaratively" then it'd make more sense.

Raymond Roestenburg

I have used it so far in two real projects very successfully. both are in the near real-time traffic information field (traffic as in cars on highways), distributed over several nodes, integrating messages between several parties, reliable backend systems. I'm not at liberty to give specifics on clients yet, when I do get the OK maybe it can be added as a reference.

Akka has really pulled through on those projects, even though we started when it was on version 0.7. (we are using scala by the way)

One of the big advantages is the ease at which you can compose a system out of actors and messages with almost no boilerplating, it scales extremely well without all the complexities of hand-rolled threading and you get asynchronous message passing between objects almost for free.

It is very good in modeling any type of asynchronous message handling. I would prefer to write any type of (web) services system in this style than any other style. (Have you ever tried to write an asynchronous web service (server side) with JAX-WS? that's a lot of plumbing). So I would say any system that does not want to hang on one of its components because everything is implicitly called using synchronous methods, and that one component is locking on something. It is very stable and the let-it-crash + supervisor solution to failure really works well. Everything is easy to setup programmatically and not hard to unit test.

Then there are the excellent add-on modules. The Camel module really plugs in well into Akka and enables such easy development of asynchronous services with configurable endpoints.

I'm very happy with the framework and it is becoming a defacto standard for the connected systems that we build.

What is the benefit of this approach in comparison to using a messaging backend (e.g. ActiveMQ) for message passing in your opinion?

MQ products are really for a different use case. different guarantees and very different performance. MQ products need a lot of setup, you would not use queues in such a product in the same way as you would use objects. Actors are first class citizens in akka, you use them as you please, similar to how you would use objects, so there is far less of an overhead both in your programming model as in the setup. MQ products you would use more to integrate with other external systems, not to build the 'internals' of a system, which is something you would use actors for.

New URL for the DBP case study is downloads.typesafe.com/website/casestudies/…

Building off @RaymondRoestenburg re: MQ systems and alternatives. RabbitMQ, for example, is built on an actor-based programming language, Erlang. That's one way to think about the relation (and distinction) between actor and MQ. Meanwhile Apache Spark is neither worker-and-queue nor Actor-based, BUT can be used with Akka: Typesafe demonstrates how to use Spark Streaming with Akka.

@RaymondRoestenburg You neglected to mention that the Actor model as-is promotes spaghetti-like structure. The "Akka in Action" book you wrote is the best demonstration for this "feature". The code examples deal with fairly basic stories. Yet the workflow is very difficult to comprehend and follow from the code. A related problem is that Akka code will be IRREVERSIBLY all over your business logic in the most intrusive way you could imagine. Much more than any other non-actor framework. It is simply impossible to write a basic workflow without dissecting it into different separate sections.

Viktor Klang

Disclaimer: I am the PO for Akka

Besides offering a concurrency smorgasbord that is much simpler to reason about and to get correct (actors, agents, dataflow concurrency) and with concurrency control in the form of STM.

Here are some use-cases you might consider:

Transaction processing (online gaming, finance, statistics, betting, social media, telecom, ...) scale up, scale out, fault-tolerance / HA Service backend (any industry, any app) service REST, SOAP, cometd etc act as message hub / integration layer scale up, scale out, fault-tolerance / HA Snap-in concurrency/parallelism ( any app ) Correct Simple to work with and understand Just add the jars to your existing JVM project (use Scala, Java, Groovy or JRuby) Batch processing ( any industry ) Camel integration to hook up with batch data sources Actors divide and conquer the batch workloads Communications hub ( telecom, web media, mobile media ) scale up, scale out, fault-tolerance / HA Game server (online gaming, betting) scale up, scale out, fault-tolerance / HA BI/datamining/general purpose crunching scale up, scale out, fault-tolerance / HA insert other nice use cases here

I understand the benefits of Futures and STM but don't find good use cases for actors. For a game or betting server, what's the advantage of using Actors vs multiple app servers behind a load balancer?

@ViktorKlang POs != Tech Lead. They work together, but are different roles.

surfmuggle

An example of how we use it would be on a priority queue of debit/credit card transactions. We have millions of these and the effort of the work depends on the input string type. If the transaction is of type CHECK we have very little processing but if it is a point of sale then there is lots to do such as merge with meta data (category, label, tags, etc) and provide services (email/sms alerts, fraud detection, low funds balance, etc). Based on the input type we compose classes of various traits (called mixins) necessary to handle the job and then perform the work. All of these jobs come into the same queue in realtime mode from different financial institutions. Once the data is cleansed it is sent to different data stores for persistence, analytics, or pushed to a socket connection, or to Lift comet actor. Working actors are constantly self load balancing the work so that we can process the data as fast as possible. We can also snap in additional services, persistence models, and stm for critical decision points.

The Erlang OTP style message passing on the JVM makes a great system for developing realtime systems on the shoulders of existing libraries and application servers.

Akka allows you to do message passing like you would in a traditional esb but with speed! It also gives you tools in the framework to manage the vast amount of actor pools, remote nodes, and fault tolerance that you need for your solution.

So is it fair to say it is case of (some) long-latency requests, where single-thread per request would not scale well?

I think the important part of actor programming in general is message flow. Once you start conceptualizing in flows of data that does not have side effects you just want as many flows to happen per node as possible. This is much different than High Performance Computing were you have semi homogenous jobs that do not send messages and take a long time to process. I think an actor based Fibonacci implementation is a very limiting example as it does not showcase why to use actors but only that actors paralyze taks. Think Event-driven architecture for use cases.

Event driven architecture is a different way of thinking about problems. It's worth reading Erlang OTP in Action from manning if you are thinking about coding in Akka. A lot of the constructs in akka are influenced by Erlang OTP and the book gives you the principles for why Jonas Boner built akka api the way he did. Akka is a big mountain that you are standing on! If your actors are persistent through state changes do you really need 10k writes a second sustained

Wade, how do you guys handle message guarantees? you mention: (email/sms alerts, fraud detection, low funds balance, etc), I assume these are potentially sent to remote actors? How do you ensure those operations actually happened? what if the node failed while processing a fraud alert? Is it gone forever? Do you have an eventually consistent system that cleans it up? thanks!

Good question James. It is obvious that it fits in a system where reply is not needed urgently. For example you can process credit card bills; calculate; send e-mail etc. I really wonder how these things (transaction) are handled when a reply is needed. At the end; if a request is made from external (internet user; a representative from call center etc.); he or she waits a reply. How can I be sure that sub tasks (which are executed async) are executed; in a xa transaction so that I can return reply?

piotrga

We use Akka to process REST calls asynchronously - together with async web server (Netty-based) we can achieve 10 fold improvement on the number of users served per node/server, comparing to traditional thread per user request model.

Tell it to your boss that your AWS hosting bill is going to drop by the factor of 10 and it is a no-brainer! Shh... dont tell it to Amazon though... :)

And I forgot to mention that the monadic nature of akka futures, which leads to much cleaner parallel code saved us thousands in code maintenance...

I assume calls are high-latency, low throughput? Like making calls to other servers, waiting for response (proxy)?

Luciano Fiandesio

We are using Akka in a large scale Telco project (unfortunately I can't disclose a lot of details). Akka actors are deployed and accessed remotely by a web application. In this way, we have a simplified RPC model based on Google protobuffer and we achieve parallelism using Akka Futures. So far, this model has worked brilliantly. One note: we are using the Java API.

Could you tell us a bit more please? Afaik Futures can't be sent over the wire (serialized). Do you use a lot of futures and few actors or a mix between the two or...? You use protobuf for all serialization and send as a message to the actors?

This seems like it could have been handled just as easily without Akka.

TDC is Telco company in Fiaddesio's case.

tylerweir

If you abstract the chat server up a level, then you get the answer.

Akka provides a messaging system that is akin to Erlang's "let it crash" mentality.

So examples are things that need varying levels of durability and reliability of messaging:

Chat server

Network layer for an MMO

Financial data pump

Notification system for an iPhone/mobile/whatever app

REST Server

Maybe something akin to WebMachine (guess)

The nice things about Akka are the choices it affords for persistence, it's STM implementation, REST server and fault-tolerance.

Don't get annoyed by the example of a chat server, think of it as an example of a certain class of solution.

With all their excellent documentation, I feel like a gap is this exact question, use-cases and examples. Keeping in mind the examples are non-trivial.

(Written with only experience of watching videos and playing with the source, I have implemented nothing using akka.)

Thanks -- I didn't mean chat server is necessarily bad, just that I would want complementary examples; easier to get better idea of potential.

Curious to know how the REST server fits here? Are you mentioning it in context of Node.js style async server? Thanks for sharing the example use cases. I found them useful.

rossputin

We use Akka in several projects at work, the most interesting of which is related to vehicle crash repair. Primarily in the UK but now expanding to the US, Asia, Australasia and Europe. We use actors to ensure that crash repair information is provided realtime to enable the safe and cost effective repair of vehicles.

The question with Akka is really more 'what can't you do with Akka'. Its ability to integrate with powerful frameworks, its powerful abstraction and all of the fault tolerance aspects make it a very comprehensive toolkit.

So which aspect do you like most if you had to choose? Existing integration for other frameworks, automatic fault tolerance, or something else?

From a personal perspective it is the raised abstraction level which Akka brings to the table that I like best. From an enterprise perspective it is the integration capabilities. Got to make a living and Akka covers business and pleasure both very nicely :-)

Could you elaborate how the flow of messages is? Is the user the person in a repair shop and enters details about the crash into a http-form and then sends the data to the server. Does this create a message that is handled by akka? To do what with this message? Extract the entered information to query the database and then queue the reply to send it back to the web-frontend?

Joa Ebert

You can use Akka for several different kinds of things.

I was working on a website, where I migrated the technology stack to Scala and Akka. We used it for pretty much everything that happened on the website. Even though you might think a Chat example is bad, all are basically the same:

Live updates on the website (e.g. views, likes, ...)

Showing live user comments

Notification services

Search and all other kinds of services

Especially the live updates are easy since they boil down to what a Chat example ist. The services part is another interesting topic because you can simply choose to use remote actors and even if your app is not clustered, you can deploy it to different machines with ease.

I am also using Akka for a PCB autorouter application with the idea of being able to scale from a laptop to a data center. The more power you give it, the better the result will be. This is extremely hard to implement if you try to use usual concurrency because Akka gives you also location transparency.

Currently as a free time project, I am building a web framework using only actors. Again the benefits are scalability from a single machine to an entire cluster of machines. Besides, using a message driven approach makes your software service oriented from the start. You have all those nice components, talking to each other but not necessarily knowing each other, living on the same machine, not even in the same data center.

And since Google Reader shut down I started with a RSS reader, using Akka of course. It is all about encapsulated services for me. As a conclusion: The actor model itself is what you should adopt first and Akka is a very reliable framework helping you to implement it with a lot of benefits you will receive along the way.

Hello Joe, could you explain how messages are used to update the site? Do you have one system for the content author; he creates a new article and hits save. Does this create a message that is send to several servers that handle the incoming traffic. Each server processes the update-message as soon as they can. Every fresh browser-request then gets an updated version of the page? Thank you

sutanu dalui

I was trying out my hands on Akka (Java api). What I tried was to compare Akka's actor based concurrency model with that of plain Java concurrency model (java.util.concurrent classes).

The use case was a simple canonical map reduce implementation of character count. The dataset was a collection of randomly generated strings (400 chars in length), and calculate the number of vowels in them.

For Akka I used a BalancedDispatcher(for load balancing amongst threads) and RoundRobinRouter (to keep a limit on my function actors). For Java, I used simple fork join technique (implemented without any work stealing algorithm) that would fork map/reduce executions and join the results. Intermediate results were held in blocking queues to make even the joining as parallel as possible. Probably, if I am not wrong, that would mimic somehow the "mailbox" concept of Akka actors, where they receive messages.

Observation: Till medium loads (~50000 string input) the results were comparable, varying slightly in different iterations. However, as I increased my load to ~100000 it would hang the Java solution. I configured the Java solution with 20-30 threads under this condition and it failed in all iterations.

Increasing the load to 1000000, was fatal for Akka as well. I can share the code with anyone interested to have a cross check.

So for me, it seems Akka scales out better than traditional Java multithreaded solution. And probably the reason is the under the hood magic of Scala.

If I can model a problem domain as an event driven message passing one, I think Akka is a good choice for the JVM.

Test performed on: Java version:1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. 3GB ram. Intel Core i5 processor, 2.5 GHz clock speed

Please note, the problem domain used for the test can be debated and I tried to be as much fair as my Java knowledge allowed :-)

"I can share the code with anyone interested to have a cross check." I would like to if you don't mind.

I would also like the code, can you post a github link ?

Thank you for your interest. Unfortunately I have some problems setting up a github repo. If you can give me your emails, I can mail over the source code. And regrets for a late reply!

@sutanudalui Do you still have the code please, if so I can share my email ?

Matthias L. Jugel

We are using akka with its camel plugin to distribute our analysis and trending processing for twimpact.com. We have to process between 50 and 1000 messages per second. In addition to multi-node processing with camel it is also used to distribute work on a single processor to multiple workers for maximum performance. Works quite well, but requires some understanding of how to handle congestions.

are you also using Akka's fault tolerance?

How about Spark Streaming if we you have access to Spark cluster?

Arseniy Zhizhelev

We use Akka in spoken dialog systems (primetalk). Both internally and externally. In order to simultaneously run a lot of telephony channels on a single cluster node it is obviously necessary to have some multithreading framework. Akka works just perfect. We have previous nightmare with the java-concurrency. And with Akka it is just like a swing — it simply works. Robust and reliable. 24*7, non-stop.

Inside a channel we have real-time stream of events that are processed in parallel. In particular: - lengthy automatic speech recognition — is done with an actor; - audio output producer that mixes a few audio sources (including synthesized speech); - text-to-speech conversion is a separate set of actors shared between channels; - semantic and knowledge processing.

To make interconnections of complex signal processing we use SynapseGrid. It has the benefit of compile-time checking of the DataFlow in the complex actor systems.

Daniel Ribeiro

I've recently implemented the canonical map-reduce example in Akka: Word count. So it's one use case of Akka: better performance. It was more of a experiment of JRuby and Akka's actors than anything else, but it also shows that Akka is not Scala or Java only: it works on all languages on top of JVM.

Do you know what is responsible for better performance (and also compared to which alternative)? Is that due to using JRuby on JVM (vs native Ruby), scalalibiliy due to non-blocking I/O or something else?

The comparison I wrote was: Jruby sequential VS Jruby with actors. Therefore, the only thing that can be responsible for faster execution is the participation of the actors. No I/O participated on the experiments (a file is load from disk, but it is done before the benchmark timer is set).

I've recently implemented a map reduce example as well, but it's just plain vanilla java github.com/chaostheory/jibenakka

What are the best use cases for Akka framework [closed]

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US