Reactive Programming, Traits and Principles. What is Reactive, where does it come from, and what is it good for? How does it differ from event driven programming? It only functional?

1. Reactive Programming with Examples
London Java Community and Skills Matter eXchange.
Thursday 20th November 2014
Peter Lawrey, CEO
Higher Frequency Trading Ltd.

2. Agenda
• What is Reactive Programming?
• History behind reactive programming
• What are the traits of reactive programming?
• Reactive design with state machines.

3. Reactive means
Reactive
a) Readily response to a stimulus.
-- merriam-webster.com

4. Reactive means …
Reactive
a) Readily response to a stimulus.
b) Occurring as a result of stress
or emotional upset.
-- merriam-webster.com

5. What is Reactive Programming?
“In computing, reactive programming is
a programming paradigm oriented around data
flows and the propagation of change.” –
Wikipedia.
Reactive Systems “are Responsive, Resilient,
Elastic and Message Driven” – Reactive
Manifesto.

6. What is Reactive Programming?
Reactive Programming and Design is a higher level
description of the flow of data rather than dealing
with individual elements or events.
Map<String, List<Position>> positionBySymbol =
positions.values().stream()
.filter(p -> p.getQuantity() != 0)
.collect(groupingBy(Position::getSymbol));

7. What Reactive Programming isn’t?
Procedural Programming
Polling to check what has changed
e.g. ad hoc queries.
Same as event driven programming.
Same as functional programming

8. In the beginning there was the Callback
• Function pointers used in assembly, C and others.
• Could specify code to call when something changed
(Event driven)
• Could specify code to inject to perform an action
void qsort(void* field,
size_t nElements,
size_t sizeOfAnElement,
int(_USERENTRY *cmpFunc)(const void*, const void*));

9. Model View Controller architecture
1970s and 1980s
• First used in the 1970s by Xerox Parc by Trygve
Reenskaug.
• Added to smalltalk-80 with almost no documentation
• "A Cookbook for Using the Model-View-Controller User
Interface Paradigm in Smalltalk -80", by Glenn Krasner
and Stephen Pope in Aug/Sep 1988.
• Event driven design.

10. Embedded SQL (1989)
• Compiler extension to allow SQL to be written in C, C++,
Fortran, Ada, Pascal, PL/1, COBOL.
for (;;) {
EXEC SQL fetch democursor;
if (strncmp(SQLSTATE, "00", 2) != 0)
break;
printf("%s %sn",fname, lname);
}
if (strncmp(SQLSTATE, "02", 2) != 0)
printf("SQLSTATE after fetch is %sn", SQLSTATE);
EXEC SQL close democursor;
EXEC SQL free democursor;

11. Gang of Four, Observer pattern (1994)
• Described Observerables and Observers.
• Focuses on event driven, not streams.
• Added to Java in 1996.
• No manipulation of observerables.
Observable o = new Observable();
o.addObservable(new MyObserver());
o.notifyObservers(new MyEvent());

12. InputStream/OutputStream in Java (1996)
• Construct new streams by wrapping streams
• Socket streams were event driven.
• TCP/UDP inherently asynchronous.
• Very low level byte manipulation
InputStream is = socket.getInputStream();
InputStream zipped = new GZIPInputStream(is);
InputStream objects = new ObjectInputStream(zipped);
Object o = objects.readObject();

13. Staged Event-Driven Architecture (2000)
• Based on a paper by Matt Welsh
• “Highly Concurrent Server Applications”
• A set of event driven stages separated by queues.
• Libraries to support SEDA have been added.

14. Reactive Extensions in .NET 2009
• Built on LINQ added in 2007.
• Combines Observable + LINQ + Thread pools
• Functional manipulation of streams of data.
• High level interface.
var customers = new ObservableCollection<Customer>();
var customerChanges = Observable.FromEventPattern(
(EventHandler<NotifyCollectionChangedEventArgs> ev)
=> new NotifyCollectionChangedEventHandler(ev),
ev => customers.CollectionChanged += ev,
ev => customers.CollectionChanged -= ev);

15. Reactive Extensions in .NET (cont)
var watchForNewCustomersFromWashington =
from c in customerChanges
where c.EventArgs.Action == NotifyCollectionChangedAction.Add
from cus in c.EventArgs.NewItems.Cast<Customer>().ToObservable()
where cus.Region == "WA"
select cus;
watchForNewCustomersFromWashington.Subscribe(cus => {
Console.WriteLine("Customer {0}:", cus.CustomerName);
foreach (var order in cus.Orders) {
Console.WriteLine("Order {0}: {1}", order.OrderId,
order.OrderDate);
}
});

16. • library for composing asynchronous and event-based programs by
using observable sequences.
• It extends the observer pattern to support sequences of data/events
and adds operators that allow you to compose sequences together
declaratively
• abstracting away concerns about things like low-level threading,
synchronization, thread-safety, concurrent data structures, and non-blocking
I/O
RxJava
Observable.from(names).subscribe(new Action1<String>() {
@Override
public void call(String s) {
System.out.println("Hello " + s + "!");
}
});

17. Akka Framework
• process messages asynchronously using an event-driven receive loop
• raise the abstraction level and make it much easier to write, test,
understand and maintain concurrent and/or distributed systems
• focus on workflow—how the messages flow in the system—instead of
low level primitives like threads, locks and socket IO
case class Greeting(who: String)
class GreetingActor extends Actor with ActorLogging {
def receive = {
case Greeting(who) ⇒ log.info("Hello " + who)
}
}
val system = ActorSystem("MySystem")
val greeter = system.actorOf(Props[GreetingActor], name = "greeter")
greeter ! Greeting("Charlie Parker")

18. Reactor Framework
• a foundation for asynchronous applications on the JVM.
• make building event and data-driven applications easier
• process around 15,000,000 events per second
• Uses Chronicle Queue for a persisted queue
// U() is a static helper method to create a UriTemplateSelector
reactor.on(U("/topic/{name}"), ev -> {
String name = ev.getHeaders().get("name");
// process the message
});

19. Reactive System traits
• Responsive – React in a timely manner
respond with reliable latencies.
• Resilient – React to failure,
handle failure well instead of trying to prevent them
• Elastic – React to load
• Message Driven – React to events.
See the Reactive Manifesto for more details

20. Messages, Event Driven, Actors
• A message is a self contain piece of information
• Messaging systems are concerned about how they are
delivered, rather than what they contain.
• A messaging system has a header for meta information.

21. Messages, Event Driven, Actors
• Events state what has happened. They are associated with the
source of an event and need not have a listener.
• The fact an event happened doesn’t imply an action to take.
• Similar to Publish/Subscribe messaging.
• Lose coupling between producer and consumer.
• Can have multiple consumers for the same event.

22. Messages, Event Driven, Actors
• Actors-based messages are commands to be executed by a
specific target. Actor-based messages imply an action to take
as well as who should take it.
• It usually doesn’t have a reason, or trigger associated with it.
• Similar to asynchronous Point-to-point or Request/Reply
messaging.
• Tighter coupling between the producer and an actor.

23. Reactive principles
• Avoid blocking on IO (or anything else) use futures
• Pass blocking tasks to supporting thread.
• Monitor your core threads to report any delays and their cause.
E.g. take a stack trace if your event loop takes more than 5 ms.
• Avoid holding locks (ideally avoid locks)
• Pre-build your listener layout. Don’t dynamically add/remove
listeners. Create a structure which is basically static in layout.

24. Reactive principles – don’t forget testing
• Reproducable inputs and load. Complete replayability
• Deterministic behavior, diagnose rare bug in stateful components.
• Controlled timings, diagnose rare timing issues.

25. Reactive Performance
• Event Driven programming improves latency on average and
worst timings, sometimes at the cost to throughput.
• There is ways to tune event driven systems to handle bursts in
load which start to look more procedural.
• Reactive systems should be performant so they are relatively
lightly loaded, so they can always be ready to react.
If you have to respond in 20 ms or 200 μs, you want this to be
the 99%tile or 99.99%tile latency not the average latency.

26. Performance considerations
• Micro burst activity. A system which experiences micro bursts is
not 1% busy, its 100% busy 1% of the time.
• Eventual consistency vs strong consistency
• Process every event, or just the latest state.
By taking the latest state you can absorb high bursts in load.
• Reactive systems which is relatively lightly loaded, so they can
always be ready to react.

27. Functional Reactive Quality
• Improves quality of code, esp for more junior developers.
An Empirical Study on Program Comprehension
with Reactive Programming – Guido Salvaneschi

28. Functional Reactive Programming
• No mutable state
• Easy to reason about
• Easy to componentize
• But … no mutable state.

29. State Machines
• Local mutable state
• Easier to reason about, than shared state
• Easier to componentize
• Not as simple as FRP.

30. FRP with a State Machine
• Minimum of local mutable state
• Easier to reason about, than shared state
• Easier to componentize

31. A typical trading system

32. Reactive means always being ready.
Questions and answers
Peter Lawrey
@PeterLawrey
http://higherfrequencytrading.com