Akka Part 1

Why Akka ?

Most of us have done multithreading in the past won’t deny how hard and painful it is to manage multithreaded applications or concurrent applications.
Having to deal with threads, locks, race conditions, and so on is highly error-prone and can lead to code that is difficult to read, test, and maintain.
It aches when you see that you don’t have a easier way to recover from errors in your sub-tasks OR those zombie bugs that you find hard to reproduce OR when your profiler shows that your threads are spending a lot of time blocking wastefully before writing to a shared state.

What is the Akka Framework?

Akka is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant applications on the JVM. Akka is written in Scala, with language bindings provided for both Scala and Java.
Akka’s approach to handling concurrency is based on the Actor Model

WHAT ARE ACTORS?

Treat Actors like Employee and HR Department,Employee sits in some remote location and HR at some other location and they both interact with mails.
So what all happens ??

MESSAGING :

So employee sends an email to HR form his INBOX and HR replies to the email from his INBOX.

CONCURRENCY

Now, imagine there are multiple employees sending requests to multiple HR departments to handle different type of requests
Nothing changes actually. Everybody has their own mailbox.

FAILOVER.

There can be chances when any HR is on sick leave or something, So there has to to some one who can handle his work for that day, So a member of the same team
steps up and replied to employees queries.
Points to note :

1. There could be a pool of Actors who does different things.
2. An Actor could do something that causes an exception. It wouldn’t be able to recover by itself. In which case a new Actor could be created in place of the old one. Alternatively, the Actor could just ignore that one particular message and proceed with the rest of the messages.

MULTITASKING

There is a possiblity that the same HR is involved in medical incurance and employee engagement, So the same HR can handle multiple type of requests.

CHAINING.

There is a possibility that you have sent a mails to HR, and all the HR’s are sending you a consolidated mail containing resolution of all your queries.
i.e we an make an hierarchy that will be followed by the HR team for replying to any query.
So lets here define the ACTOR model.

1. So employee and HR become our ACTOR’s
2. Mailbox can be considered as a queue from which data is going to be taken up and processed.
3. Mail messages are immutable objects.
4. There is a component that delivers
   message composed in the source inbox to the recipient inbox, lets
   call it, Message Dispatcher.