reactive applications using akka

miguelinlas3@gmail.com - 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

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

Shared Memory

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

Going Event Driven

Shared Memory

Thread 1 Thread 2

Going Event Driven

Shared Memory

Thread 1 Thread 2

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

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

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

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

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7

Supervision strategies: One for one

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

Supervision strategies: One for all

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B6

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

System

/A1/A2

/A1/A2/A4

/A1/A3

/B1/B2

/B1/B2/B4

/B1/B3

/B1/B3/B5

/B1/B2/B6

/B1/B2/B7B5

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

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

References: frameworks and toolkits

Erlang

Akka Toolkit

Scala language

Vert.x

Clojure language

References: frameworks and toolkits

Cloud Haskell

NodeJS

Netty IO

Finagle

reactive applications using akka

shared memory

actor model

13 actor model

correct lock

event driven

return observable

object message

post println

Technology

distributed data analytics thorsten papenbrock akka actor...

reactive integrations with akka streams

reactive streams / akka streams - geecon prague 2014

reactive programming with akka - lessons learned

reactive on-line machine learning with akka...

how reactive streams & akka streams change the jvm ecosystem

delivering transformative reactive systems on openshift...

reactive fast data & the data lake with akka, kafka, spark

akka http: the reactive web...

introduction to reactive with play and akka - markus jura

[tokyo scala user group] akka streams & reactive streams...

building reactive applications with akka

tdc2017 | poa trilha programacao funcional - reactive...

reactive apps with akka and...

reactive microservices with play and akka

building reactive systems with akka

reactive applications and akka intro used in the madrid...

reactive programming with scala, lagom, spark, akka and play

akka - home: doag e.v. · what are reactive applications?...

developing distributed applications with akka and akka...