Reactive applications using Akka

Miguel Ángel Pastor Olivar
Reactive Applications
Building concurrent and distributed apps using Akka
miguelinlas3@gmail.com - Liferay Inc and MadridJUG
@miguelinlas3

Saturday, October 19, 13

About me

Writing software for the Liferay platform team
Phd student? on distributed and cloud
systems
Scala enthusiast
Twitter: @miguelinlas3


Agenda

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)


Reactive applications

Applications has become extremely
demanding
New kind of systems
Event driven, scalable , resilient, responsive
This is what Reactive Applications are all
about


Reactive applications: definitions

Blocking
Caller blocked. Wait for the results
Non blocking
Caller not blocked. Need to pool
Asynchronous
Caller not blocked. Select, epoll, signals
Event driven
Message flowing through the system

Basic pillars


Basic pillars

Event Driven


Basic pillars

Event Driven

Resilient


Basic pillars

Event Driven

Resilient


Scalable

Basic pillars

Event Driven

Resilient

Scalable

Responsive


Going event driven
Old known problems,
The actor model


Going Event Driven


Going Event Driven

Shared Memory


Going Event Driven

Thread 1

Shared Memory


Going Event Driven

Thread 1

Thread 2

Shared Memory


Going Event Driven

Thread 1

Thread 2

R/W

Shared Memory


Going Event Driven

Thread 1

Thread 2

R/W
R/W

Shared Memory


Going Event Driven

Thread 1

Thread 2

R/W
R/W

Shared Memory


AVOID IT!!

Going event driven: problems with locks



Composition



Composition
Locks don´t compose



Composition


Granularity


Composition
Have I taken too few
locks? Too many?


Granularity


Composition
locks? Too many?

Encapsulation


Granularity


Composition
locks? Too many?

Encapsulation
Breaking abstractions


Granularity


Composition

Granularity

locks? Too many?

Encapsulation


Correctness


Composition

Granularity

locks? Too many?

Encapsulation

Correctness

Have I taken the
correct lock?



Composition

Granularity

locks? Too many?

Encapsulation

Ordering


Correctness

Have I taken the
correct lock?


Composition

Granularity

locks? Too many?

Encapsulation

Ordering


Have I used the
correct order?

Correctness

Have I taken the
correct lock?

Going event driven: designing your system

Asynchronous message/event passing
Workflow of the events through your system
Benefits:
Better throughput
Lower latencies
Loosely coupled solutions


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 {
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 {
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");
}

Dealing with routers does not change our code
metricsActor.tell(
new JVMMessage("JVM-MemoryUsage", new Date().getTime()));


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"
}
}
}
}

No changes are required in our existing code!!
final ActorSystem monitoringServiceSystem =
ActorSystem.create("MonitoringServiceSystem");
ActorRef metricsActor = monitoringServiceSystem.actorOf(
new Props(MetricsProcessorActor.class), "metricsActor");


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 programming
Tangled within business logic
Scattered along all our codebase

Going resilient: actor topology and supervision

System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3
B7
B5

/A1/A2/A4

A4

B6

B4

/B1/B3/B5
/B1/B2/B6


/B1/B2/B7

/B1/B2/B4

Supervision strategies: One for one

System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3
B7
B5

/A1/A2/A4

A4

B6

B4

/B1/B3/B5
/B1/B2/B6


/B1/B2/B7

/B1/B2/B4

Supervision strategies: One for one

System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3
B7

/A1/A2/A4

A4

B6

B4

/B1/B3/B5
/B1/B2/B6


/B1/B2/B7

/B1/B2/B4

Supervision strategies: One for all
System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3
B7
B5

/A1/A2/A4

A4

B6

B4

/B1/B3/B5
/B1/B2/B6


/B1/B2/B7

/B1/B2/B4

System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3
B7

/A1/A2/A4

A4

B6

B4

/B1/B3/B5
/B1/B2/B6


/B1/B2/B7

/B1/B2/B4

System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3
B7
B5

/A1/A2/A4

A4

/B1/B2/B7
/B1/B3/B5
/B1/B2/B6


B4

/B1/B2/B4

System

/B1

/A1

B1

A1

/B1/B3

/A1/A2

/B1/B2

B3
B2

A2

/A1/A3
A3

B5

/A1/A2/A4

A4

B6

B4

/B1/B3/B5
/B1/B2/B6


/B1/B2/B7

/B1/B2/B4

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 conﬁgure 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 Failure
f onComplete {
case Success(posts) => for (post <- posts) println(post)
case Failure(t) => println("An error has occured: " +
t.getMessage)
}
// only handle Success
f onSuccess {
case posts => for (post <- posts) println(post)
}
// only handle Failure
f 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 agent
val counter = Agent(0)
// send the function: enqueued the change
counter send { _ + 1}
// long running or blocking operations
implicit val ec = defineSomeExecutionContext()
agent sendOff blockingOperation
// read the agent’ s value
val agentValue = counter.value


More tools: software transactional memory

Sometimes we will deal with shared state
Heap + 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
nextElement
nextElement
nextElement
nextElement


=>
=>
=>
=>
=>

foo_10_transformed
foo_11_transformed
foo_12_transformed
foo_13_transformed
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 core
Logic or functional programming
Futures and/or dataflow
Non-determinism when needed
Actors, Agents or Rx
Shared mutability
Protected by Software Transactional Memory
Finally, only if it is really needed
Locks 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

hammer

When all you have is a
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
GPars


References: frameworks and toolkits

Cloud Haskell
NodeJS
Netty IO
Finagle


Reactive applications using Akka

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Reactive applications using Akka

Semelhante a Reactive applications using Akka (20)

Mais de Miguel Pastor

Mais de Miguel Pastor (18)

Último

Último (20)

Reactive applications using Akka