London Java Community and Skills Matter eXchange.Thursday 20th November 2014

Peter Lawrey, CEO

Higher Frequency Trading Ltd.

Reactive Programming with Examples

• What is Reactive Programming?

• History behind reactive programming

• What are the traits of reactive programming?

• Reactive design with state machines.

Agenda

Reactive means

Reactive

a) Readily response to a stimulus.

-- merriam-webster.com

Reactive means …

Reactive

a) Readily response to a stimulus.

b) Occurring as a result of stress or emotional upset.

-- merriam-webster.com

“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.

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.

What is Reactive Programming?

Map<String, List<Position>> positionBySymbol =

positions.values().stream()

.filter(p -> p.getQuantity() != 0)

.collect(groupingBy(Position::getSymbol));

Procedural Programming

Polling to check what has changede.g. ad hoc queries.

Same as event driven programming.

Same as functional programming

What Reactive Programming isn’t?

• 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

In the beginning there was the Callback

void qsort(void* field,

size_t nElements,

size_t sizeOfAnElement,

int(_USERENTRY *cmpFunc)(const void*, const void*));

• 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.

Model View Controller architecture1970s and 1980s

• Compiler extension to allow SQL to be written in C, C++, Fortran, Ada, Pascal, PL/1, COBOL.

Embedded SQL (1989)

for (;;) { EXEC SQL fetch democursor; if (strncmp(SQLSTATE, "00", 2) != 0) break; printf("%s %s\n",fname, lname);}if (strncmp(SQLSTATE, "02", 2) != 0) printf("SQLSTATE after fetch is %s\n", SQLSTATE);EXEC SQL close democursor;EXEC SQL free democursor;

• Described Observerables and Observers.

• Focuses on event driven, not streams.

• Added to Java in 1996.

• No manipulation of observerables.

Gang of Four, Observer pattern (1994)

Observable o = new Observable();

o.addObservable(new MyObserver());

o.notifyObservers(new MyEvent());

• Construct new streams by wrapping streams

• Socket streams were event driven.

• TCP/UDP inherently asynchronous.

• Very low level byte manipulation

InputStream/OutputStream in Java (1996)

InputStream is = socket.getInputStream();

InputStream zipped = new GZIPInputStream(is);

InputStream objects = new ObjectInputStream(zipped);

Object o = objects.readObject();

• 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.

Staged Event-Driven Architecture (2000)

• Built on LINQ added in 2007.

• Combines Observable + LINQ + Thread pools

• Functional manipulation of streams of data.

• High level interface.

Reactive Extensions in .NET 2009

var customers = new ObservableCollection<Customer>();var customerChanges = Observable.FromEventPattern( (EventHandler<NotifyCollectionChangedEventArgs> ev) => new NotifyCollectionChangedEventHandler(ev), ev => customers.CollectionChanged += ev, ev => customers.CollectionChanged -= ev);

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

Reactive Extensions in .NET (cont)

• 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 + "!"); }});

• 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

Akka Framework

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

• 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

Reactor Framework

// 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

});

• 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

Reactive System traits

• 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.

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.

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.

Messages, Event Driven, Actors

• 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.

Reactive principles

• Reproducable inputs and load. Complete replayability

• Deterministic behavior, diagnose rare bug in stateful components.

• Controlled timings, diagnose rare timing issues.

Reactive principles – don’t forget testing

• 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.

Reactive Performance

• 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.

Performance considerations

• Improves quality of code, esp for more junior developers.

An Empirical Study on Program Comprehension

with Reactive Programming – Guido Salvaneschi

Functional Reactive Quality

• No mutable state

• Easy to reason about

• Easy to componentize

• But … no mutable state.

Functional Reactive Programming

• Local mutable state

• Easier to reason about, than shared state

• Easier to componentize

• Not as simple as FRP.

State Machines

• Minimum of local mutable state

• Easier to reason about, than shared state

• Easier to componentize

FRP with a State Machine

A typical trading system

Questions and answers

Peter Lawrey

@PeterLawrey

http://higherfrequencytrading.com

Reactive means always being ready.