Software analysts around the world anticipate a concept of "Reactive Programming" to have a great future in solving the problems of big data, high load and mobile applications. TypeSafe, the developers of Scala language, created a promising "reactive" framework Akka, written in Scala and yet Java-friendly. How could it be interesting for Java developers? Can Akka+Java compete with Akka+Scala? How Java8 can help with that? This presentations provides answers to these questions. This presentation by Dmytro Mantula (Lead Software Engineer, GlobalLogic) was delivered at GlobalLogic Java Conference #2 in Krakow on April 23, 2016. This presentation is also available in Russian: http://www.slideshare.net/GlobalLogicUkraine/take-a-look-at-akka-java

1. TAKE A LOOK AT
AKKA + JAVA
Dmytro Mantula
GlobalLogic, Kyiv

2. PREVIOUS AGE OF COMPUTING SYSTEMS
• Monolith software architecture
• Managed servers and containers
• RDBMS, transactions isolation
• Scalability: scale-up by more powerful hardware
• Proprietary enterprise solutions

3. NEW CHALLENGES
• response time: s -> ms
• high availability: 3 nines (8h/y) -> 5+ nines (5– m/y)
• storage: GBs (10
9
) -> PBs (10
15
)+
• hardware: spread from mobile phone to 1000+
nodes cluster

4. MOORE’S LAW

5. EVIL OF CPU PERFORMANCE:
MOORE’S LAW
DOESN’T WORK
ANYMORE
FOR A SINGLE CORE

6. The more CPU cores a system
has,
the faster it is.
True or false?

7. EVIL OF PARALLELISM:
AMDAHL’S LAW
Gene Amdahl
1967

8. STUBBORN AMDAHL’S LAW
The speedup of a program
using multiple processors in parallel computing
is limited by the sequential fraction of the program.

9. EVIL OF CONCURRENCY:
SHARED MUTABLE
STATE

10. «Do not communicate
by sharing memory.
Instead, share memory
by communicating»
– Effective Go

11. v1.0: July 2013
v2.0: Sept 2014
REACTIVE SOFTWARE DESIGN
http://www.reactivemanifesto.org/

12. • rapid and consistent response times
• response in SLA time may be more
important than late correct response
• problems may be detected quickly
and dealt with effectively
react to users
Responsive

13. v1.0: July 2013
v2.0: Sept 2014
REACTIVE SOFTWARE DESIGN
http://www.reactivemanifesto.org/

14. react to load
Elastic
• No contention points or central bottlenecks
• ability to shard or replicate components
and distribute inputs among them
• Automatic resource management
• scale-up
• scale-out
• scale-down
• scale-in

15. v1.0: July 2013
v2.0: Sept 2014
REACTIVE SOFTWARE DESIGN
http://www.reactivemanifesto.org/

16. • “Let it crash!”: there is no way to think
about every single failure point
• failure is not dealt with as an error
• means that some capacity of the
system will be reduced
• dealt with as a message
react to failures
Resilient

17. v1.0: July 2013
v2.0: Sept 2014
REACTIVE SOFTWARE DESIGN
http://www.reactivemanifesto.org/

18. Asynchronous message-passing
• loose coupling
• isolation of components
• location transparency
• failures as messages
Benefits:
• load management
• elasticity
• flow control (monitoring , back-pressure)
react to events
Message Driven

19. Application
should be reactive
from top to
bottom

20. v1.0: July 2013
v2.0: Sept 2014
REACTIVE SOFTWARE DESIGN
http://www.reactivemanifesto.org/

21. CARL HEWITT, 1973
ACTOR MODEL
• Describes:
• message processing algorithm
• data storage principles
• interaction between modules
• Erlang
• Used in telecommunication systems
• High Availability of 9 “nines”

22. • Written in Scala
• Stable since 2009
• Part of Scala Standard Library since 2013
• Supports Java 8 since 2014
by
ex

23. WHAT IS AN ACTOR?
Actor is a unit of code
with a mailbox
and an internal state
that just responds to messages
in a single thread
(briefly)

24. IDLE
TWO STATES OF ACTOR

25. IDLE
TWO STATES OF ACTOR
MESSAGE PROCESSING

26. WHAT IS AN ACTOR?
• Similar to object in OOP, but message-driven
• Even more isolated than object: no explicit access
exposed (hidden behind ActorRef)
• no shared state
• location transparent (can live in different JVMs)
• Light-weight: 300B memory footprint (millions per GB)
• No threads allocated in idle state
• Single-threaded invocation inside, sequential message
processing
• Supervises children actors

27. WHAT CAN ACTOR DO?
• If no messages being processed:
• Nothing
• When message being processed (one at a time):
• make local decisions
• send messages to other actors (incl. sender() and self())
• do other actions with side-effects (IO, logs, DB access)
• change own behavior for next messages
• create more actors (and promise to supervise them)

28. BENEFITS
• You’re not going to have multiple threads modifying a
variable at the same time.
• Forget about:
• Shared state
• Threads
• Locks, “synchronized”
• Concurrent collections
• wait/notify/notifyAll
• Describe only business behavior in the code.
• Akka and app configuration care about everything else.

29. MESSAGE CLASS
• Obligatory: purely-immutable
• Desirably: serializable
• Good practice: declared with recipient Actor class

30. MESSAGE CLASS
• Obligatory: purely-immutable
• Desirably: serializable
• Good practice: declared with recipient Actor class
SCALA:

31. ACTOR IN JAVA 7

32. ACTOR IN JAVA 7
Strict @Override

33. ACTOR IN JAVA 7
Casting boilerplate
Strict @Override

34. ACTOR IN JAVA 7
Casting boilerplate
Strict @Override
“if” hell

35. ACTOR IN JAVA 7
Casting boilerplate
Strict @Override
“if” hell
Do not forget!!!

36. ACTOR IN JAVA 8

37. Partial function
ACTOR IN JAVA 8

38. Partial function
Behavior
as a constant
ACTOR IN JAVA 8

39. Partial function
Behavior
as a constant
Type
inference
within lambda
ACTOR IN JAVA 8

40. Partial function
Behavior
as a constant
Type
inference
within lambda
ACTOR IN JAVA 8
Predicate

41. ACTORSYSTEM AND ENTRY POINT

42. DONEC QUIS NUNC
SUPERVISION MODEL

43. ROUTING
• RoundRobin
• Random
• SmallestMailbox
• Broadcast
• ScatterGatherFirstCompleted
• (Custom)

44. REMOTE ACTORS

45. WHERE TO USE AKKA?
• Multi-user concurrency (e.g. gambling systems)
• Rule based systems (like trading systems)
• Data storages with lots of write operations
• Systems with high-uptime requirements (like telecom)
• Processing pipelines
• Streaming data
• Reactive frameworks

46. DERIVATIVE FRAMEWORKS/TOOLS
• For testing actors: Akka TestKit
• Software Transactional Memory: Akka STM
• Finite State Machines: Akka FSM
• Durable mailboxes & other persistence models
• Akka IO, Akka Streams, Akka Cluster
• Akka HTTP (ex. Spray)
• Play Framework
• Akka Camel, Akka Spring
• Activator

47. RESOURCES
http://akka.io/
http://lightbend.com
http://letitcrash.com
Coursera:
Principles of Reactive Programming

48. THANKS!
Q & A