Reactive applications using Akka

[email protected] - Liferay Inc and MadridJUG

@miguelinlas3

Miguel Ángel Pastor Olivar

Reactive ApplicationsBuilding concurrent and distributed apps using Akka

Saturday, October 19, 13

Writing software for the Liferay platform team

About me

Phd student? on distributed and cloud systems

Scala enthusiast

Twitter: @miguelinlas3


Reactive apps: do we really need them?

Crash course on basic Akka concepts

Old known problems

A quick look into newer (and more fun tools)

Agenda


Applications has become extremely demanding

New kind of systems

Event driven, scalable , resilient, responsive

This is what Reactive Applications are all about

Reactive applications


BlockingCaller blocked. Wait for the results

Non blockingCaller not blocked. Need to pool

AsynchronousCaller not blocked. Select, epoll, signals

Event drivenMessage flowing through the system

Reactive applications: definitions


Basic pillars


Basic pillars

Event Driven


Basic pillars

Event Driven

Resilient


Basic pillars

Event Driven

Resilient Scalable


Basic pillars

Event Driven

Responsive

Resilient Scalable


Going event driven

Old known problems,The actor model


Going Event Driven


Going Event Driven

Shared Memory


Going Event Driven

Shared Memory

Thread 1


Going Event Driven

Shared Memory

Thread 1 Thread 2


Going Event Driven

Shared Memory

Thread 1 Thread 2

R/W


Going Event Driven

Shared Memory

Thread 1 Thread 2

R/WR/W


Going Event Driven

Shared Memory

Thread 1 Thread 2

R/WR/W AVOID IT!!


Going event driven: problems with locks



Composition



CompositionLocks don´t compose



Composition GranularityLocks don´t compose



Composition GranularityLocks don´t compose

Have I taken too few locks? Too many?



Composition Granularity

Encapsulation

Locks don´t compose





Encapsulation



Breaking abstractions




EncapsulationCorrectness










Have I taken the correct lock?






Ordering









Ordering




Have I used the correct order?



Asynchronous message/event passing

Workflow of the events through your system

Benefits:Better throughputLower latenciesLoosely coupled solutions

Going event driven: designing your system


Going event driven: Amdahl’s law


Going event driven: the actor model

Fundamental unit of computation that embodies:• Processing• Storage• Communication

Three axioms. When an Actor receives a message it can:• Create new Actors• Send messages to Actors it knows• Designate how it should handle the next message it receives

Carl Hewitt


http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask


Zero sharing

Isolated, lightweight event based processes

Communication through asynchronous message passing

Location transparent

Built-in supervision


Actor model: Define a new actor

public class MetricsProcessorActor extends UntypedActor {

public void onReceive(Object message) { if (message instanceof JVMMetric) { JVMMetric jvmMetric = (JVMMetric)message;

_dataStore.save(jvmMetric); } }

private DataStore _dataStore = new LogDataStore();}


Actor model: Creating an actor

ActorSystem _agentSystem = ActorSystem.create("AgentSystem");

ActorRef metricsActor = _agentSystem.actorOf(

new Props(new UntypedActorFactory() { @Override public Actor create() {

return new MetricsActor(metricsActor);}

}),"metricsActor");


Actor model: Getting a reference

ActorSystem _agentSystem = ActorSystem.create("AgentSystem");

ActorRef handshakeActor = _agentSystem.actorFor(

"akka://MonitoringServiceSystem@localhost:5557/user/handshakeActor");


Actor model: Sending a message

metricsActor.tell(new JVMMessage("JVM-MemoryUsage", new Date().getTime()));


Actor model: Replying to a message

public class HandshakeActor extends UntypedActor {

public void onReceive(Object message) {

if (message instanceof AuthMessage) { AuthMessage authMessage = (AuthMessage)message;

if (authMessage.getUser() == "migue" && authMessage.getCredentials() == "migue")

getSender().tell("ok"); else

getSender().tell("fail"); } else throw new IllegalStateException("Unable to handle " +

message); }}


Actor model: Switching implementation

public class MetricsProcessorActor extends UntypedActor {

public void onReceive(Object message) { if (message instanceof SwappingMessage) { getContext().become(altPersistence, false) }

} Procedure<Object> altPersistence = new Procedure<Object>() { @Override public void apply(Object message) { altDatastore.save(message); }

DataStore altDatastore = new AltDataStore();};

private DataStore _dataStore = new LogDataStore();}


Actor model: Routing

final ActorSystem monitoringServiceSystem =ActorSystem.create("MonitoringServiceSystem");

ActorRef metricsActor = monitoringServiceSystem.actorOf(

new Props(MetricsProcessorActor.class).withRouter( new RoundRobinRouter(100), "metricsActor"); }

metricsActor.tell(new JVMMessage("JVM-MemoryUsage", new Date().getTime()));

Dealing with routers does not change our code


Actor model: Configuring a router

akka { actor { deployment { /metricsActor { router = round-robin nr-of-instances = 100 } } }}


Going scalable

Distributed computing,The actor model


Going scalable: scalability

I really do have an scalability problem ...

if my system is fast for a single user but slow when the system is under heavy load


Going scalable: transparent distributed computing

Distributed shared mutable state

Distributed objects

Distributed transactions



Synchronous method dispatching across the network is a bad idea

Ignores partial failures

Raises Latency

General scalability and DC concerns



EMBRACE THE NETWORK!!


Going scalable: remote actors

akka { actor { deployment { /metricsActor {

remote = "akka://monitorSystem@name:5557"

} } }}

final ActorSystem monitoringServiceSystem =ActorSystem.create("MonitoringServiceSystem");

ActorRef metricsActor = monitoringServiceSystem.actorOf( new Props(MetricsProcessorActor.class), "metricsActor");

No changes are required in our existing code!!


Going resilient

Error handling


Going resilient: common problems

Single thread of control

Thread blows up --> you are screwed

Error handling within single thread

Errors don´t get propagated

Defensive programmingTangled within business logicScattered along all our codebase


Going resilient: actor topology and supervision

System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B5

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7


Supervision strategies: One for one

System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B5

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5


Supervision strategies: One for all

System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B5

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B6

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B6

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B6

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

B7

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B6

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B6

B7



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B6



System

A1

A2

A4

B1

B2

B4

B3

A3

/A1

/A1/A2

/A1/A2/A4

/A1/A3

/B1

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

B6

B7


Going resilient: configure supervision

final SupervisorStrategy supervisorStrategy = new OneForOneStrategy(

3, Duration.create(1, TimeUnit.MINUTES),new Class<?>[] {Exception.class});

_metricsActor = _cloudServiceSystem.actorOf( new Props(MetricsProcessorActor.class).

withRouter( new RoundRobinRouter(100).

withSupervisorStrategy( supervisorStrategy)),

"metricsActor");

Supervision strategies are pluggable and you can develop and configure your own


More tools

We deserve better and more fun tools


More tools: futures

•Spawn concurrent computations

•Write once - Read many

•Freely sharable

•Non-blocking composition

•Composable (monadic operations)

•Managing failure


More tools: futures

val f: Future[List[String]] = future { session.getRecentPosts}

// handle both cases: Success and Failuref onComplete { case Success(posts) => for (post <- posts) println(post) case Failure(t) => println("An error has occured: " +

t.getMessage)}

// only handle Successf onSuccess { case posts => for (post <- posts) println(post)}

// only handle Failuref onFailure { case t => println("An error has occured: " + t.getMessage)}


More tools: agents

•Reactive memory cells

•Send update function to an agent

•Reads are “free”

•Composable

•Originally in Clojure, borrowed by Akka


More tools: agents

// declare the agentval counter = Agent(0)

// send the function: enqueued the changecounter send { _ + 1}

// long running or blocking operations

implicit val ec = defineSomeExecutionContext()agent sendOff blockingOperation

// read the agent’ s valueval agentValue = counter.value


More tools: software transactional memory

Sometimes we will deal with shared stateHeap + Stack: transactional dataset:

Begin, commit, rollback

Retry on collision

Rollback on abort

Transaction composability


More tools: reactive extensions

•Futures + Stream concept

•Composables

•Async and event based

•Push collections

•JVM available through the RxJava project



def simpleComposition() { customObservableNonBlocking() .skip(10) .take(5) .map({ stringValue -> return stringValue + "_transformed"}) .subscribe({ println "nextElement => " + it})} // we should an output like this

nextElement => foo_10_transformednextElement => foo_11_transformednextElement => foo_12_transformednextElement => foo_13_transformednextElement => foo_14_transformed



def Observable<T> getData(int id) { if(availableInMemory) { return Observable.create({ observer -> observer.onNext(valueFromMemory); observer.onCompleted(); }) } else { return Observable.create({ observer -> executor.submit({ try { T value = getValueFromRemoteService(id); observer.onNext(value); observer.onCompleted(); }catch(Exception e) { observer.onError(e); } }) }); }}


Useful approaches

Where should I use each tool?


Layers of complexity

Declarative & immutable coreLogic or functional programmingFutures and/or dataflow

Non-determinism when neededActors, Agents or Rx

Shared mutabilityProtected by Software Transactional Memory

Finally, only if it is really neededLocks and explicit threads


Takeways

A quick summary


Takeaways

Go reactive

Avoid locking (share nothing, lock free algs)

Already in the JVM? Akka could be good choice

Distributed systems are hard

Use the correct level of abstraction

And remember ...


Takeaways

When all you have is a hammer everything looks like

a nail.

Choose the

right tool for your job!


Questions?

And let’s hope answers


References

Interesting resources


References: slides, talks and books

High Performance Networking in the JVM by Eric Onnen

Going reactive talk by Jonas Bonér

Introducing Akka by Jonas Bonér

The future I was promised by Viktor Klang

Real world Akka recipes by Björn Antonsson et all


http://www.slideshare.net/eonnen/high-performance-network-programming-on-the-jvm-oscon-2012

http://www.slideshare.net/eonnen/high-performance-network-programming-on-the-jvm-oscon-2012

http://www.slideshare.net/jboner/going-reactive-eventdriven-scalable-resilient-systems

http://www.slideshare.net/jboner/going-reactive-eventdriven-scalable-resilient-systems

http://www.slideshare.net/jboner/introducing-akka

http://www.slideshare.net/jboner/introducing-akka

http://skillsmatter.com/podcast/design-architecture/the-future-i-was-promised

http://skillsmatter.com/podcast/design-architecture/the-future-i-was-promised

http://www.slideshare.net/shinolajla/real-world-akka-recepies-v3

http://www.slideshare.net/shinolajla/real-world-akka-recepies-v3

References: slides, talks and books

Programming Concurrency in the JVM: Mastering synchronization, STM and Actors by Venkat Subramaniam

Systems than run forever Self-heal by Joe Amstrong

The art of multiprocessor programming, Revised Reprint by Maurice Herlihy

Reactive Manifesto


http://pragprog.com/book/vspcon/programming-concurrency-on-the-jvm




http://www.infoq.com/presentations/self-heal-scalable-system

http://www.infoq.com/presentations/self-heal-scalable-system

http://www.amazon.com/The-Multiprocessor-Programming-Revised-Reprint/dp/0123973376




http://www.reactivemanifesto.org/

http://www.reactivemanifesto.org/

References: frameworks and toolkits

Erlang

Akka Toolkit

Scala language

Vert.x

Clojure language

GPars


http://erlang.org

http://erlang.org

http://akka.io

http://akka.io

http://www.scala-lang.org/

http://www.scala-lang.org/

http://vertx.io/

http://vertx.io/

http://clojure.org/

http://clojure.org/

http://gpars.codehaus.org/

http://gpars.codehaus.org/

References: frameworks and toolkits

Cloud Haskell

NodeJS

Netty IO

Finagle


http://nodejs.org/

http://nodejs.org/

http://nodejs.org/

http://nodejs.org/

http://netty.io/

http://netty.io/

http://twitter.github.io/finagle/

http://twitter.github.io/finagle/

Reactive applications using Akka

Technology

Transcript of Reactive applications using Akka