I have heard lots of raving about [Akka][1] 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)

  [1]: http://akka.io/

What are the best use cases for Akka framework

Newbie question of Akka - I&#39;m reading over Akka Essentials, could someone please explain the difference between Akka Stop/Poison Pill vs. Kill ? The book offers just a small explaination &quot;Kill is synchronous vs. Poison pill is asynchronous.&quot; But in what way? Does the calling actor thread lock during this time? Are the children actors notified during kill, post-stop envoked, etc? Example uses of one concept vs. the other?

Many thanks!


Akka Kill vs. Stop vs. Poison Pill?

I&#39;ve already read the question and answers to [What design decisions would favour Scala&#39;s Actors instead of JMS?][1].

Usually, we use messaging solutions which have existed for years already: either a JMS implementation such as WebSphere MQ or Apache ActiveMQ is used for Point-To-Point communication, or Tibco Rendevous for Multicast messaging.

They are very stable, proven and offer high availability and performance. Nevertheless, configuration and setup seem much more complex than in Akka.

When and why should I use Akka for some use cases where the aforementioned products - WebSphere MQ or ActiveMQ - have been used successfully so far? Why should I consider using Akka instead of WebSphere MQ or Tibco RV in my future project? 

And when should I avoid Akka? Does it offer the same high availability and performance as the other solutions? Or is it a bad idea to even compare Akka to the other messaging middlewares?

Maybe there also is another messaging solution in the JVM environment which I should consider besides JMS (Point-to-Point), TibcoRV (Multicast) and Akka?

  [1]: https://stackoverflow.com/q/4648280/1305344

When to use actors instead of messaging solutions such as WebSphere MQ or Tibco Rendezvous?

I&#39;ve been looking at akka recently and it&#39;s pretty impressive. It looks like it has most of the killer features of erlang - location transparency, supervision hierarchies, and more. Are there any features erlang has that akka doesn&#39;t?

How does akka compare to Erlang?

I&#39;ve worked with `Node.js` for a little while and consider myself pretty good with Java.  But I just discovered `Akka` and was immediately interested in its actor pattern (from what I understand).

Now, assuming my JavaScript skills were on par with my Scala/Java skills, I want to focus on the practicality of either system.  Especially in the terms of web services.

It was my understanding that Node is excellent at handling many concurrent operations.  I imagine a good Node web service for an asset management system would excel at handling many users submitting changes at the same time (in a large, heavy traffic application).

But after reading about the actors in Akka, it seams it would excel at the same thing.  And I like the idea of reducing work to bite-sized pieces.  Plus, years ago I dabbled in Erlang and fell in love with the message passing system it uses.

I work on many applications that deal with complex business logic and I&#39;m thinking it&#39;s time to jump heavier into one or the other.  Especially upgrading legacy Struts and C# applications.

Anyway, avoiding holy wars, how are the two systems fundamentally different?  It seems both are geared towards the same goal.  With maybe Akka&#39;s &quot;self-healing&quot; architecture having an advantage.

**EDIT**

It looks like I am getting close votes.  Please don&#39;t take this question as a &quot;which is better, node or akka?&quot;.  What I am looking for is the fundamental differences in event driven libraries like Node and actor based ones like Akka.

How is Node.js evented system different than the actor pattern of Akka?

I am in the process of starting a new project (java-based). I need to build it as a modular, distributed and resilient architecture.

Therefore I would like to have the business processes to communicate among themselves, be interoperable, but also independent.

I am looking right now at two frameworks that, besides their difference in age, express 2 different views:

 - Akka (http://akka.io)
 - Reactor (https://github.com/reactor/reactor)

What I should  consider when choosing one of the above frameworks?

As far as I understand till now, Akka is still somehow coupled (in a way that I have to &#39;choose&#39; the actor I want to send the messages to), but very resilient. While Reactor is loose (as is based on event posting).

Can someone help me understand how make a proper decision?

**UPDATE**

After reviewing better the [Event Bus][1] of Akka, I believe in some way the [features expressed by Reactor][2] are already included in Akka.

For example the subscription and event publishing, documented on https://github.com/reactor/reactor#events-selectors-and-consumers, can be expressed in Akka as following:


    final ActorSystem system = ActorSystem.create(&quot;system&quot;);
	final ActorRef actor = system.actorOf(new Props(
		new UntypedActorFactory() {

			@Override
			public Actor create() throws Exception {

				return new UntypedActor() {
					final LoggingAdapter log = Logging.getLogger(
							getContext().system(), this);

					@Override
					public void onReceive(Object message)
							throws Exception {
						if (message instanceof String)
							log.info(&quot;Received String message: {}&quot;,
									message);
						else
							unhandled(message);
					}
				};
			}
		}), &quot;actor&quot;);

	system.eventStream().subscribe(actor, String.class);
	system.eventStream().publish(&quot;testing 1 2 3&quot;);


Therefore it seems to me now that the major differences between the two are:

 - Akka, more mature, bound to Typesafe
 - Reactor, early stage, bound to Spring

Is my interpretation correct? But **what is conceptually the difference between the Actor in Akka and the Consumer in Reactor**?


  [1]: http://doc.akka.io/docs/akka/snapshot/java/event-bus.html
  [2]: https://github.com/reactor/reactor#events-selectors-and-consumers

Akka or Reactor

What is the difference between exclamation mark (`!`) and question mark (`?`) when sending messages to Actors?

    myActor ! Hello(value1)
    myActor ? Hello(value1)

Akka in Scala, exclamation mark and question mark

I found there is also an Akka actor model, so I am wondering what&#39;s the difference between the Akka&#39;s Actor and Scala&#39;s Actor model?

What&#39;s the difference of the Akka&#39;s Actor with Scala&#39;s Actor model

With the release of Scala 2.9.0, the Typesafe Stack  was also announced, which combines the Scala language with the Akka framework. Now, though Scala has actors in its standard library, Akka uses its own implementation. And, if we look for other implementations, we&#39;ll also find that Lift and Scalaz have implementations too!

So, what is the difference between these implementations?

How are the multiple Actors implementation in Scala different?

I am currently trying to get started with Akka and I am facing a weird problem. I&#39;ve got the following code for my Actor:

    class AkkaWorkerFT extends Actor {
      def receive = {
        case Work(n, c) if n &lt; 0 =&gt; throw new Exception(&quot;Negative number&quot;)
        case Work(n, c) =&gt; self reply n.isProbablePrime(c);
      }
    }

And this is how I start my workers:

    val workers = Vector.fill(nrOfWorkers)(actorOf[AkkaWorkerFT].start());
    val router = Routing.loadBalancerActor(SmallestMailboxFirstIterator(workers)).start()

And this is how I shut everything down:

    futures.foreach( _.await )
    router ! Broadcast(PoisonPill)
    router ! PoisonPill

Now what happens is if I send the workers messages with n &gt; 0 (no exception is thrown), everything works fine and the application shuts down properly. However, as soon as I send it a single message which results in an exception, the application does not terminate because there is still an actor running, but I can&#39;t figure out where it comes from.

In case it helps, this is the stack of the thread in question:

      Thread [akka:event-driven:dispatcher:event:handler-6] (Suspended)	
    	Unsafe.park(boolean, long) line: not available [native method]	
    	LockSupport.park(Object) line: 158	
    	AbstractQueuedSynchronizer$ConditionObject.await() line: 1987	
    	LinkedBlockingQueue&lt;E&gt;.take() line: 399	
    	ThreadPoolExecutor.getTask() line: 947	
    	ThreadPoolExecutor$Worker.run() line: 907	
    	MonitorableThread(Thread).run() line: 680	
    	MonitorableThread.run() line: 182	

PS: The thread which is not terminating isn&#39;t any of the worker threads, because I&#39;ve added a postStop callback, every one of them stops properly.

PPS: `Actors.registry.shutdownAll` workarounds the problem, but I think shutdownAll should only be used as a last resort, shouldn&#39;t it?

Akka Actor not terminating if an exception is thrown

So, if I have an actor, I can give it a name. But, can I access that name internally? Example:

    class Actorz extends Actor with ActorLogging {
       val actorName = //??What function

       def receive = {
         case x =&gt; log.debug(actorName+&quot;: Received Message: &quot;+x)
       }
    }

    val actor = system.actorOf(Props[Actorz], &quot;named&quot;)
    actor ! &quot;dogs&quot;

Now, I can pass its name as a constructor parameter. But, that seems like unnecessary duplication if there is a way to get the name internally... as it was set when I instantiated the actor using `system.actorOf`. API docs didn&#39;t seem to have anything.

How can I get the name of an Akka actor from within the actor itself?

I&#39;m new to the Akka framework and I&#39;m building an HTTP server application on top of Netty + Akka.

My idea so far is to create an actor for each type of request. E.g. I would have an actor for a POST to /my-resource and another actor for a GET to /my-resource.

Where I&#39;m confused is how I should go about actor creation? Should I:

1. Create a new actor for every request (by this I mean for every request should I do a TypedActor.newInstance() of the appropriate actor)? How expensive is it to create a new actor? 

2. Create one instance of each actor on server start up and use that actor instance for every request? I&#39;ve read that an actor can only process one message at a time, so couldn&#39;t this be a bottle neck?

3. Do something else?

Thanks for any feedback.



Akka - How many instances of an actor should you create?

Could you please tell me the difference between Apache Spark and AKKA, I know that both frameworks meant to programme distributed and parallel computations, yet i don&#39;t see the link or the difference between them.

Moreover, I would like to get the use cases suitable for each of them.


Apache Spark vs Akka

***Note:*** *Unfortunately this question was closed, but I&#39;m trying to maintain it for if someone else comes along with the same question.*

I&#39;ve been looking for a good solution to developing a service in Scala that will sit between mobile devices and existing web services.

The current list of viable options are:

 - [Finagle][1]
 - [Spray][2]
 - [BlueEyes][3]
 - [Akka][4]
 - [Play2 Mini][5]
 - [Unfiltered][6]
 - [Lift][7]
 - [Smoke][8]
 - [Scalatra][11]

There are probably more options out there. How does one decide which one to use? What are the traits (excuse the pun ;-) of a good Scala middleware choice. On the one side, I would like to go for Akka, because it is part of the TypeSafe Scala stack, but on the other, something like Finagle has a rich set of libraries and makes plumbing so easy. Spray looks nice and simple to use.

Any advice, insights or experience would be greatly appreciated. I&#39;m sure someone out there must have some experience with some of these that they won&#39;t mind sharing.

**UPDATE:**

I would love for this question to be reopened. A good answer to this question will help new Scalateers to avoid related pitfalls.

**UPDATE 2:**

These are my own experiences since asking this question:

*Finagle* - I used Finagle for a project and it&#39;s rock solid.

*Spray* - In my latest project I&#39;m using Spray and I&#39;m extremely happy. The latest releases are built on Akka 2 and you can run it directly with the Spray-can library which removes the need for a web server. Spray is a set of libraries, rather than a framework and is very modular. The [Learn about Spray: REST on Akka video][9] gives a great overview, and [this blog at Cakesolutions][10] shows a really nice development approach and architecture.

**UPDATE 3:**

Life moves pretty fast. If you don&#39;t stop and look around once in a while, you could miss it. - _Ferris Bueller_

These days the choice has become simpler. In my humble opinion Spray has won the battle. It is being [integrated into Akka][12] to become the next Akka HTTP. I have been using Spray now on multiple projects and can honestly say that it&#39;s fantastic and best supported software I have ever encountered.

This does not answer the initial question, but at least gives some indication on why Spray seems like the best choice in most cases. It is extremely flexible, non-blocking and very stable. It has both client-side and server-side libraries and a great testkit. Also, have a look at these stats to get an idea on performance: [Web Framework Benchmarks][13]

  [1]: http://twitter.github.com/finagle
  [2]: https://github.com/spray
  [3]: https://github.com/jdegoes/blueeyes
  [4]: http://akka.io/
  [5]: https://github.com/typesafehub/play2-mini/
  [6]: http://unfiltered.databinder.net/Unfiltered.html
  [7]: http://liftweb.net/
  [8]: https://github.com/mDialog/smoke
  [9]: http://marakana.com/s/spray_rest_on_akka_from_the_northeast_scala_symposium,1150/index.html
  [10]: http://www.cakesolutions.net/teamblogs/2012/07/29/api-first-rest-in-akka-and-spray/
  [11]: http://www.scalatra.org/
  [12]: http://typesafe.com/blog/typesafe-gets-sprayed
  [13]: http://www.techempower.com/benchmarks/#section=data-r7&amp;hw=i7&amp;test=json

What are the differences between Scala middleware choices?

I am trying to leverage Akka&#39;s finite state machine framework for my use case. I am working on a system that processes a request that goes through various states.

The request here is the application name that needs to be deployed along with the application it depends on:

    Request for application A -&gt; A is in a QUEUED state
    Discover A&#39;s dependency B -&gt; B is in a QUEUED state
    B is being processed -&gt; B is in a PROCESSING STATE
    A is being processed -&gt; A is in a PROCESSING STATE
    B is processed -&gt; B is in a DONE state
    A is processed -&gt; A is in a DONE state

For this I am initializing a finite state machine at discovery time. So `A`&#39;s FSM is created when the request comes in, `B`&#39;s FSM is initialized when `B` is discovered from one of the actors.

Do I initialize and pass the FSM instance to all the actors, and at the same time `tell` the FSM about the operations being performed on the data so that the state machine goes in the correct state?

Here is the relevant portion of the state machine:

    when(QUEUED, matchEvent(requestAccepted.class, MyApp.class,
        (requestAccepted, service) -&gt; 
        goTo(PROCESSING).replying(PROCESSING)));
    
    when(PROCESSING, matchEvent(completed.class, MyApp.class,
        (completed, service) -&gt; goTo(DONE).replying(DONE)));

    // During transitions, save states in the database.
    onTransition(matchState(PROCESSING, DONE, () -&gt; {
      nextStateData().setServiceStatus(DONE);
      databaseWriter.tell(nextStateData(), getSelf());

And here is an example from one of the actors processing the request:

    ProcessingActor extends AbstractActor {
    
        @Override
          public void onReceive(Object message) throws Throwable {
            if (message instanceof processApplication) {
             // process the app
             // Initialize FSM for the Application
             FSM myFSM = Props.create(MYFSM.class);
             myFSM.tell( new completed(processApplication.app)
        }

Is this the right way to initialize the state machine and use it? Or should the initialization happen in the constructor of the `ProcessingActor`? But in that case there wouldn&#39;t be one state machine per application (data).


Akka finite state machine instances

Akka 2.x requires many commands to reference an `ActorSystem`.  So, to create an instance of an actor `MyActor` you might say:

&lt;!-- language: scala --&gt;

    val system = ActorSystem()
    val myActor = system.actorOf(Props[MyActor])

Because of the frequent need for an `ActorSystem`: many code examples omit the creation from the code and assume that the reader knows where a `system` variable has come from. 

If your code produces actors in different places, you could duplicate this code, possibly creating additional `ActorSystem` instances, or you could try to share the same `ActorSystem` instance by referring to some global or by passing the `ActorSystem` around.

The Akka documentation provides a [general overview of systems of actors](http://doc.akka.io/docs/akka/2.0.1/general/actor-systems.html) under the heading &#39;Actor Systems&#39;, and there is [documentation of the `ActorSystem` class](http://doc.akka.io/api/akka/2.0.1/#akka.actor.ActorSystem).  But neither of these help a great deal in explaining why a user of Akka can&#39;t just rely on Akka to manage this under-the-hood.

Question(s)
-----------

* What are the implications of sharing the same `ActorSystem` object or creating a new one each time?

* What are the best practices here? Passing around an `ActorSystem` all the time seems surprisingly heavy-handed.

* Some examples give the `ActorSystem` a name: `ActorSystem(&quot;MySystem&quot;)` others just call `ActorSystem()`.  What difference does this make, and what if you use the same name twice?

* Does `akka-testkit` require that you share a common `ActorSystem` with the one you pass to the `TestKit` constructor?

Do I need to re-use the same Akka ActorSystem or can I just create one every time I need one?

What is a difference between tell and forward, in case I will send the same message:

    case msg: Message =&gt;
      otherActor tell (msg,sender)

 and

    case msg: Message =&gt;
      otherActor forward msg
     

Difference between forward and tell in akka actors

[Play&#39;s home page](http://www.playframework.com/) says:

&gt; Built on Akka, Play provides predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications.

I&#39;d like to know exactly how and where Akka is used in Play and what are the consequences of having Play build on top of Akka.

How is Akka used in Play?

I would like to create a `Source` and later push elements on it, like in:

    val src = ... // create the Source here
    // and then, do something like this
    pushElement(x1, src)
    pushElement(x2, src)

What is the recommended way to do this?

Thanks!

How to create a Source that can receive elements later via a method call?

I am learning Scala and Akka and in my recent lookup for a [solution][1], I found something like  

     case class TotalTaxResult(taxAmount:Double)
     case object TaxCalculationTimeout

What is the difference between the two?

When should I use one over the other?

  [1]: https://stackoverflow.com/questions/22770927/waiting-for-multiple-results-in-akka

Difference between case class and case object?

Am a Scala programmer and understand Akka from a developer point of view. I have not looked into Akka library&#39;s code. Have read about the two types of actors in the Akka model - thread-based and event-based - but not having run Akka at large scale I dont have experience of configuring Akka for production. And am completely new to Vert.x. So, from the choices perspective to build a reactive application stack I want to know -

 1. Is the message-passing model of Akka and Vert.x very different? How?
 2. Are the data-structures behind Akka&#39;s actors and Vert.x&#39;s verticles to buffer messages very different?


Difference in message-passing model of Akka and Vert.x

I&#39;m trying to find the &#39;right&#39; actor implementation. I realized there is a bunch of them and it&#39;s a bit confusing to pick one. Personally I&#39;m especially interested in remote actors, but I guess a complete overview would be helpful to many others. This is a pretty general question, so feel free to answer just for the implementation you know about.

I know about the following Scala Actor implementations (SAI). Please add the missing ones.

- Scala 2.7 (difference to)
- Scala 2.8
- Akka (http://www.akkasource.org/)
- Lift (http://liftweb.net/)
- Scalaz (http://code.google.com/p/scalaz/)
--- --- --- --- --- --- --- --- --- --- --- --- 
- What are the target use-cases for these SAIs (lightweight vs. &quot;heavy&quot; enterprise framework)?
- do they support remote actors? What shortcomings do remote actors have in the SAIs?
- How is their performace?
- How active is there community?
- How easy are they to get started? How good is the documentation?
- How easy are they to extend? 
- How stable are they? Which projects are using them?
- What are their shortcomings?
- What are their design principles?
  - Are they thread based or event based (receive/ react) or both?
  - Nested receiveS
  - hotswapping the Actor’s message loop

All Akka Solutions on Gang of Coders

Total of 22 Akka Solutions