1. Concurrency, Scalability & Fault-tolerance 2.0 with Actors & STM by Mario Fusco mario.fusco@gmail.com twitter: @mariofusco

2. Which are the biggestchallengesin contemporary software development?

3. Deal with overloadedsystems

4. Do concurrencyeffectively

5. Design, develop and deployapplicationsthat scale well

6. The native Java concurrency model Based on: Threads Semaphores Synchronization Locks They are sometimes plain evil … … and sometimes a necessary pain … … but always the wrong default

8. Share NOTHING

9. Isolated lightweight processes

10. Communicates through messages

11. Asynchronous and non-blocking

12. Each actor has a mailbox (message queue)

15. Written in Scala, butalsoworking in Java

16. Nowrealeasing 1.0 after 2 years of development (currentlyRC4 available)

17. Better performances and throughput and smallermemoryfootprint (650 bytes) than native scala actors

19. Sending message to UntypedActors There are 3 different ways to send a message to an actor: Fire-and-forget ( ! In Scala ) actor.sendOneWay(msg); Uses a Future under the hood, blocking the sender Actor until eithera reply is received or the Future times out ( !! In Scala ) Object res1 = actor.sendRequestReply(msg); Object res2 = actor.sendRequestReply(msg, 1000); // timeout Explicitly returns a Future ( !!! In Scala ) Future future= actor.sendRequestReplyFuture(msg); IMPORTANT: Messages can be any kind of object but have to be immutable. Akkacan’t enforce immutability (yet) so this has to be by convention

20. Typed Actors public class CounterImplextends TypedActorimplements Counter { private int counter = 0; public void count() { counter++; System.out.println(counter); } public intgetCountNr() { returncounter; } } Counter counter= (Counter)TypedActor .newInstance(Counter.class, CounterImpl.class, 1000); counter.count(); // Fire-and-forget intcount = counter.getCountNr(); // uses Future under the hood

21. “Let it crash” fault-tolerance through supervisor hierarchies

22. You can’t avoid failures: shit happens

23. What’swrong in trying to preventerrors? Java and other languages and frameworks (not designed with concurrency in mind) signal faults/errors with exceptions Throwing an exception in concurrent code will just simply blow up the thread that currently executes the code that threw it: There is no way to find out that things went wrong, apart from inspecting the stack trace There is nothing you can do to recover from the problem and bring back your system to a normal functioning

24. Fail fast & build self-repairing systems

26. Supervised actors also allow you to create sets (hierarchies) of actors where you can be sure that either all are dead or none are dead

27. That encourages non-defensive programming: don’t try to prevent things from go wrong, because they will. Failures are a natural state in the life-cycle of your app: crash early and let someone else (that sees the whole picture), deal with it

28. A supervisor is responsible for starting, stopping and monitoring its child processes. It can act with 2 fault handling strategies:One-For-One or All-For-One

29. Declarative supervised actors configuration Supervisor supervisor = new Supervisor( new SupervisorConfig( new AllForOneStrategy( // or OneForOneStrategy new Class[]{Exception.class}, // Exceptions to handle 3, // maximum number of restart retries 5000), // within time in millis new Supervise[] { new Supervise( UntypedActor.actorOf(MyActor1.class), permanent()), // the actor will always be restarted new Supervise( UntypedActor.actorOf(MyActor2.class), temporary()) // the actor won’t be shut down normally })); // You can also link and unlink actors from a supervisor supervisor.link(actor1); supervisor.unlink(actor1);

31. Uses a very efficient and scalable I/O implementation built upon JBossNetty and Google Protocol Buffers

32. Can be secured with a cookie authentication mechanism

33. Can be bothTyped and Untyped

34. Twotypes of remote actors:

35. server-managed: run on the machine thatcreateditwhile client can lookup and obtain a proxy

38. Consistent: a transaction gets a consistent of reality

40. implement CAS (Compare-And-Swap) semantics

41. are managed and enforced by the STM for coordinated changes across many Refs

43. Unnecessarycomplexity

45. In this case an (exponential) delay isused to preventfurthercontentions

47. Persistent Datastructures Copyright Rich Hickey 2009

48. Coordinating Actors with STM public class Counter extends UntypedActor { private Ref<Integer> count = new Ref(0); private void increment() { count.set(count.get() + 1); } public void onReceive(Object incoming) throws Exception { if (incoming instanceof Coordinated) { Coordinated coordinated = (Coordinated) incoming; Object message = coordinated.getMessage(); if (message instanceof Increment) { Increment increment = (Increment) message; if (increment.hasFriend()) { increment.getFriend() .sendOneWay(coordinated.coordinate(new Increment())); } coordinated.atomic(new Atomically() { public void atomically() { increment(); } }); }}}}

49. Actors + STM = Transactors public class Counter extends UntypedTransactor { Ref<Integer> count = new Ref<Integer>(0); @Override public Set<SendTo> coordinate(Object message) { if (message instanceof Increment) { Increment increment = (Increment) message; if (increment.hasFriend()) return include(increment.getFriend(), new Increment()); } return nobody(); } public void atomically(Object message) { if (message instanceof Increment) { count.set(count.get() + 1); } } }

51. Integration with Apache Camel

52. PersistencemodulesupportingmanyNoSQL DB like: Cassandra, MongoDB, Riak, Redis, Terrastore, CouchDB, Voldemort, Hbase

53. Integration betweenAkkaSTM and JTA (Java Transaction API)

54. OSGisupport

55. Integration with Spring allowing to defineTyped Actors as Spring managed bean