Reactive Web Applications: Springone2Gx

SPRINGONE2GX
WASHINGTON, DC
Reactive Web Applications

Stephane Maldini
Rossen Stoyanchev
Unless otherwise indicated, these slides are © 2013-2014 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/
About the Speakers
• Stephane Maldini
• Reactor Project Lead
• Reactive Streams Spec contributor
• Rossen Stoyanchev
• Spring Framework committer
• Spring MVC
• WebSocket messaging (STOMP, SockJS)
Unless otherwise indicated these slides are © 2013-2014 Pivotal Software Inc. and licensed under a
Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ 2
Why are you here ?
What is Reactive ?
Why Non Blocking Matters ?
Non Blocking = Faster ?
Non Blocking = Internet Scale ?
Reactive Web App Stack
Servlet 3.0 Async Requests
• Async HTTP requests have been possible since Servlet 3.0
• Essentially: the ability to get off the Servlet container thread

• originated from Jetty continuations, CometD, etc.
• “Live” data in web apps

• e.g. HTTP streaming, long polling
• Reduce burden on server thread pool

• scatter-gather, external REST APIs, etc
Servlet 3.0 Async Requests: the bottom line
• A bit quirky, Servlet API wasn’t built for async
• Complex to grasp in its entirety + comes with some caveats

• e.g. lack of notification when client goes away
• Spring MVC provides full support for Servlet 3 async requests

• alleviates most concerns
• Effectively async can be introduced into existing applications

• … and ecosystem of libraries !
Servlet 3.1 Non-Blocking I/O
• Read and write without blocking
• Register ReadListener and WriteListener callbacks

• switches to non-blocking mode
• ServletInputStream and ServletOutputStream change behavior
• Must call isReady first before read() or write()

• if connection not ready (slow client), callback is scheduled
Servlet 3.1 Non-Blocking: the bottom line
• Carefully designed + it does provide non-blocking capability
• However not easy to use correctly, a number of pitfalls
• Many “innocent” looking parts of Servlet API may lead to blocking

• e.g. request.getParameters()
• For a good overview and perspective see Greg Wilkins’ talk

• ”Into the Wild with Servlet 3.1 Async I/O”
Reactive Streams Spec for the JVM
• Specification for non-blocking library interop
• governs exchange of data across async boundaries
• Collaborative effort
• Kaazing, Netflix, Pivotal, RedHat, Twiiter, Typesafe
• Momentum and growing ecosystem of libraries

• network, database, etc.
• On path to adoption in JDK 9 java.util.concurrent
Reactive Streams API
onSubscribe
request(n) Subscriber
Publisher Subscription cancel()
onNext*
(onError|onComplete)?
Reactive Back-Pressure
• A key part of Reactive Streams is back-pressure
• It’s a type of flow control
• Subscribers make requests for additional data
• Publishers abide and produce what has been requested
Reactive Streams for Network I/O
public interface ServerHttpRequest extends HttpRequest {
Publisher<byte[]> getBody();
public interface ServerHttpResponse extends HttpMessage {
Publisher<Void> writeWith(Publisher<byte[]> publisher);
Instead of...
public interface ServerHttpRequest extends HttpRequest {
InputStream getBody();
public interface ServerHttpResponse extends HttpMessage {
OutputStream getBody();
Reactive Streams over Servlet Runtime ?
• Servlet 3.1 provides the non-blocking capability
• Reactive Streams provides a non-blocking API with broad industry support
• A single Reactive Streams pipeline

• back-pressure through the layers (from DB to Web server)
• Jetty is actively investigating this very option
Reactive Streams and Servlet 4.0 ???
• It is under discussion in the expert group
• It would be great if it did happen
• Potential obstacle is the Java EE 8 - JDK 8 association
• Hopefully not a show-stopper since Reactive Streams is here today
Reactive Streams Over Netty
• Netty was designed from the ground up to be non-blocking
• Easy to translate to Reactive Streams semantics
• Two ongoing experiments

• RxNetty
• Reactor Net
Reactive Streams Network I/O
Akka HTTP, Vert.x, Ratpack, Reactor Net, RxNetty*
*(via RxJava-ReactiveStreams bridge)
Reactive
Web App Stack
Reactive Streams
Netty, Servlet 3.1
Web Framework
Reactive
Web App Stack
Reactive Streams
Netty, Servlet 3.1
Application
Web Framework
Reactive
Web App Stack
Reactive Streams
Netty, Servlet 3.1
HTTP
Reactive
Application Data
Streams
Broker
Web Framework
Reactive
Web App Stack
Reactive Streams
Netty, Servlet 3.1
HTTP
Application
? Reactive
Streams Data
Broker
?
Web Framework
API to compose
asynchronous
Reactive Streams
streams?
Netty, Servlet 3.1
Working with Streams
• Non-blocking services return Publisher<T> instead of <T>
• How do you attach further processing?
• Reactive Streams is a callback-based API

• becomes very nested quickly
• Need something more declarative

• it’s beyond the scope of Reactive Streams
Stream Operations
• Publisher represents a stream of data
• It’s natural to apply operations functional-style

• like the Java 8 Stream
• Need API for composing async logic

• rise above callbacks
Reactor Stream
• Project Reactor provides a Stream API
• Reactive Streams Publisher + composable operations
Streams.just('a' 'b' 'c')

.take(2)
.map(Character::toUpperCase)
.consume(System.out::println);
Reactive Extensions (Rx)
• Stream composition API based on Observer pattern
• originated at Microsoft, work by Erik Meijer
• Implemented for different languages -- RxJava, RxJS, Rx.NET, …
Observable.just('a', 'b', 'c')

.take(2)
.map(Character::toUpperCase)
.subscribe(System.out::println);
RxJava and Reactive Streams
• RxJava 1.x predates Reactive Streams and doesn’t implement it directly
• Very similar concepts, different names

• Observable-Observer vs Publisher-Subscriber
• RxJava supports “reactive pull” back-pressure
• RxJava 1.x - Reactive Streams bridge
Demo:
HeadFirst
RxNetty
• RxJava as the reactive bridge to Netty IO operations
• Immediate and embedded client/server for TCP and HTTP
• Decorating IO Read with rx.Observable and applying dynamic pull/push
• Decorating IO Write with rx.Subscriber and requesting more on flush
RxNetty … what’s up
• RxNetty has introduced Backpressure support in 0.5
• Powered by the backpressure protocol from RxJava
• Overall the API has been heavily lifted too

https://github.com/ReactiveX/RxNetty/wiki/0.5.x-FAQs
Reactor Net
• Reactive Streams as the reactive bridge to Netty and ZeroMQ IO operations
• Immediate and embedded client/server for TCP, UDP and HTTP
• Decorating IO Read with Publisher and applying dynamic pull/push
• Decorating IO Write with Subscriber and requesting more on flush
Member of the Reactor initiative
• Reactor is a maturing Reactive Streams suite of libraries
• As with a lot of the reactive libraries, observing a rapidly evolving set of API
• Precluded Reactive Streams specification work
• Now evolving and getting ready for Spring 5 Reactive story
projectreactor.io , github.com/reactor
Demo:
Back-Pressure
Async I/O with Reactive Streams
• Never block on Applications Queues :
Max(request) == Queue.capacity()
• Keep Reading : Any asynchronous handoff is non-blocking
• Make Writes Quicker : IO operation signals demand on availability
• Optimize hardware resources : Claim bounded memory and cpu
Reactive Read
One read implementation : Publisher stop-read
• Consume NIO Buffers only when requested
• request size is != bytes read
• Application stopping reads propagates back-pressure

• server buffers fill
• client buffers fill
• eventually throttles client
Reactive Write
One write implementation : Subscriber request after flush
• Request after flush indicates availability in write buffer
• Request size is != bytes written
• Write buffers filling naturally propagates back-pressure

• buffers fill
• no requests
• eventually throttles application
Serialization Concerns
• Subscription.request(n)is not absolute ( != bytes number )
• Decoding operations might produce one to many objects

• must match subscriber capacity
• Encoding operations might consume one to many byte chunks

• must match buffering capacity
• Available serialization libraries not built for chunked streams

• Jackson, Kryo, Protobuf, etc.
Demo:
Scatter-gather
Spring Reactive
Spring Reactive
• Experimental work for Spring Framework 5
• Non-blocking runtimes -- Netty, Jetty, Tomcat
• Reactive Streams over network I/O -- RxNetty, Reactor Net
• Spring web processing
Reactive Streams Publisher
@RequestMapping("/capitalize")
@ResponseBody
public Publisher<Person> capitalize(@RequestBody Publisher<Person> persons) {
// …
}
Reactor Stream
@ResponseBody
public Stream<Person> capitalize(@RequestBody Stream<Person> persons) {
return persons.map(person -> {
person.setName(person.getName().toUpperCase());
return person;
});
}
RxJava Observable
@ResponseBody
public Observable<Person> capitalize(@RequestBody Observable<Person> persons) {
return persons.map(person -> {
person.setName(person.getName().toUpperCase());
return person;
});
}
ReactiveX On the Client Side
RxJS
function() {
StreamService.connect("stream")
.flatMap(unpackCsv)
.subscribe(updateUI, logError, logComplete);
}
var unpackCsv = function (ev) {

return Rx.Observable.from(ev.data ? ev.data.split("\n") : [])
.filter(discardEmpty)
.map(csvToJson)
}
Demo:
RxJS and Ratpack
Learn More. Stay Connected.
@springcentral Spring.io/video
Thank You for Listening!

@smaldini / @rstoya05
Unless otherwise indicated, these slides are © 2013-2014 Pivotal Software, Inc. and licensed under a

Reactive Web Applications: Springone2Gx

Uploaded by

Copyright:

Available Formats

You might also like

Reactive Web Applications: Springone2Gx

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Reactive Web Applications: Springone2Gx

Uploaded by

Copyright:

Available Formats

SPRINGONE2GX

Reactive Web Applications

• Essentially: the ability to get off the Servlet container thread

• “Live” data in web apps

• Reduce burden on server thread pool

• Complex to grasp in its entirety + comes with some caveats

• Spring MVC provides full support for Servlet 3 async requests

• Effectively async can be introduced into existing applications

• Register ReadListener and WriteListener callbacks

• ServletInputStream and ServletOutputStream change behavior

• Must call isReady first before read() or write()

• However not easy to use correctly, a number of pitfalls

• Many “innocent” looking parts of Servlet API may lead to blocking

• For a good overview and perspective see Greg Wilkins’ talk

• Momentum and growing ecosystem of libraries

• On path to adoption in JDK 9 java.util.concurrent

• It’s a type of flow control

• Subscribers make requests for additional data

• Publishers abide and produce what has been requested

public interface ServerHttpRequest extends HttpRequest {

public interface ServerHttpResponse extends HttpMessage {

Publisher<Void> writeWith(Publisher<byte[]> publisher);

public interface ServerHttpRequest extends HttpRequest {

public interface ServerHttpResponse extends HttpMessage {

• Reactive Streams provides a non-blocking API with broad industry support

• A single Reactive Streams pipeline

• Jetty is actively investigating this very option

• It would be great if it did happen

• Potential obstacle is the Java EE 8 - JDK 8 association

• Hopefully not a show-stopper since Reactive Streams is here today

• Easy to translate to Reactive Streams semantics

• Two ongoing experiments

*(via RxJava-ReactiveStreams bridge)

Netty, Servlet 3.1

Netty, Servlet 3.1

Netty, Servlet 3.1

Netty, Servlet 3.1

• How do you attach further processing?

• Reactive Streams is a callback-based API

• Need something more declarative

• It’s natural to apply operations functional-style

• Need API for composing async logic

• Reactive Streams Publisher + composable operations

Streams.just('a' 'b' 'c')

• Implemented for different languages -- RxJava, RxJS, Rx.NET, …

Observable.just('a', 'b', 'c')

• Very similar concepts, different names

• RxJava supports “reactive pull” back-pressure

• RxJava 1.x - Reactive Streams bridge

• Immediate and embedded client/server for TCP and HTTP

• Decorating IO Read with rx.Observable and applying dynamic pull/push

• Decorating IO Write with rx.Subscriber and requesting more on flush

• Powered by the backpressure protocol from RxJava

• Overall the API has been heavily lifted too

• Immediate and embedded client/server for TCP, UDP and HTTP

• Decorating IO Read with Publisher and applying dynamic pull/push

• Decorating IO Write with Subscriber and requesting more on flush

• Precluded Reactive Streams specification work