In today's world, computer hardware is becoming cheaper and more powerful, as we have multiple cores on a single CPU chip. As cores keep on increasing, with the increasing power of hardware, we need a state of the art software framework which can use these cores efficiently.
Akka is such a framework, or you can say, a toolkit, which utilizes the hardware cores efficiently and lets you write performant applications.
As we are living in big data world, a lot of traffic comes to our servers, and we want our servers to respond in milliseconds instead of seconds. Akka is here to scale up the application as the load on it increases.
We want our application to run day and night continuously with high availability--Akka is here to build fault tolerance for our application.
We want to run our application on a cluster of multiple machines--Akka is here to scale out our application across the data center.
Can we do all of this using the Java multithreading model? Maybe.
Our assumption is that most of our readers have worked with the Java multithreading model, and they are aware of the fact that it is very difficult to write multithreaded concurrent applications. This is because we have to manage low-level details like locking an object, releasing the lock on the object, notifying, waiting for threads to join each other to complete a task, and freeing up resources that a thread holds. It is difficult for us to write multithreaded programs, because we have to focus more on thread management details instead of focusing on business logic only.
Akka is a toolkit for writing truly concurrent, fault-tolerant, distributed, and scalable applications, which can run for days, months, and years without stopping, and can heal themselves in case of failure. It is very hard to write concurrent applications using the plain Java multithreading model, which also satisfies fault-tolerant, distributed, and scalable properties. Akka provides a high-level of abstraction to build such an application that satisfy these properties.
Thus, Akka provides a basic unit of abstraction of transparent distribution called actors, which form the basis for writing resilient, elastic, event-driven, and responsive systems.
Let's see what is meant by these properties:
- Resilient: Applications that can heal themselves, which means they can recover from failure, and will always be responsive, even in case of failure like if we get errors or exceptions
- Elastic: A system which is responsive under varying amount of workload, that is, the system always remains responsive, irrespective of increasing or decreasing traffic, by increasing or decreasing the resources allocated to service this workload
- Message Driven: A system whose components are loosely coupled with each other and communicate using asynchronous message passing, and which reacts to those messages by taking an action
- Responsive: A system that satisfies the preceding three properties is called responsive
A system that satisfies all four properties is called a reactive system.
Properties of reactive system
Note
For more information, see Reactive manifesto (http://www.reactivemanifesto.org).
Before starting with recipes, let's take a look at the following the actor properties:
- State: An actor has internal state, which is mutated sequentially as messages are processed one by one.
- Behavior: An Actor reacts to messages which are sent to it by applying behavior on it.
- Communication: An actor communicates with other actors by sending and receiving messages to/from them.
- Mailbox: A mailbox is the queue of messages from which an actor picks up the message and processes it.
An actor's anatomy
Actors are message-driven, that is, they are passive and do nothing unless and until you send messages to them. Once you send them a message, they pick a thread from the thread pool which is also known as a dispatcher, process the message, and release the thread back to the thread pool.
Actors are also asynchronous by nature; they never block your current thread of execution, and continue to work on another thread.
Note
Visit the Wikipedia link for an actor model (https://en.wikipedia.org/wiki/Actor_model) for details.
Let's start making recipes.