Server Sent Event Processing in Spring MVC 4.2

In a previous post I spoke about the features Spring MVC 4.2 has from Streaming Request Processing. I have discussed how we can StreamingResponseBody to send large data asynchronously in a streaming manner. 

In this post I am planning to talk about SseEmitter which is another way to send semi structured data clients in an asynchronous streaming manner.

If you want to learn more about the definition and structure of a Server Sent Event you can read the Mozilla Documentation. But in short a Server Sent Event is a push event from a server which will be taking place inside of a single TCP/IP Socket connection from Client to Server. This event being push means it eliminates the need for constant polling of the Server for data thus reduces unwanted load on Server and the Client can receive the data in real time.

In Spring MVC following controller code can be written to send server sent events easily and in the client end Javascript can be used to read these events and present in the web page. For demo purpose I am showing a live Cricket match score and commentary coming down to a Web page client in real time. The server code will look like below; 

And Javascript client client code will look like below;

And as you can see from the image below there is only one request being initiated to /score end point but multiple commentary data being received through that long lived connection.

Spring Web Flux - The Non Blocking Asynchronous Functional Reactive Web Framework - 2

Spring Web Flux Framework can be used with its latest Release Candidate Release 5.0.0.RC3 if you want to try it out. You just need to add the Spring Milestone Repository in your gradle or maven file.

I have written the following service which emulates a delay of maximum 1000 milliseconds in a service to test how the conventional Spring Web MVC vs Spring Web Flux work.

And the following controller implementations one with a Blocking conventional Spring Web MVC Controller method which returns a list to get people and a Non Blocking Spring Web Flux Controller method which returns a Flux> which is a defferred result and processed differently.

And Tested sending 1000 concurrent requests to both methods using a Gatling test. The Application was running inside of a Tomcat Container.

Spring Web MVC results were

And Spring Web Flux results were

If you compare the 99th Percentile, Max and Mean response times of the both results you can see Spring Web Flux is considerably faster without any code changes to improve performance. This is a promising sign. The numbers can be improved even more if we use the Netty Reactive Servers instead of conventional Tomcat servers in my understanding.

Spring Web Flux - The Non Blocking Asynchronous Functional Reactive Web Framework - 1

Spring has a very diverse eco system of projects from Batch Jobs to Web Security. The best part of Spring project is that they are always ahead of time and do innovative work which sometimes are adopted by the Java Platform itself. For Example the @Autowired Annotation introduced by Spring was later standardized in JSR 330 as @Inject. 

Spring 5 is something they are working on right now (Have released 5.0.0 Release Candidate 3 Version as of writing this post) and has a lot of innovative features. Following are a list of those features;

• Reactive programming: introducing our Spring WebFlux framework built on Reactor 3.1, with support for RxJava 1.3 & 2.1 and running on Tomcat, Jetty, Netty or Undertow.
• Functional style with Java 8 & Kotlin: several API refinements and Kotlin extensions across the framework, in particular for bean registration and functional web endpoints.
• Integration with Java EE 8 APIs: support for Servlet 4.0, Bean Validation 2.0, JPA 2.2, as well as the JSON Binding API (as an alternative to Jackson/Gson in Spring MVC).
• Ready for JDK 9: fully aligned with JDK 9 at runtime, on the classpath as well as the module path (on the latter: as filename-based “automatic modules” for the time being).

One of most interesting is the introduction of Spring Web Flux - A Non Blocking Functional Reactive Web Framework. Reactive Programming has been alive for sometime in form of RxJava project and many more programming frameworks like Akka, NodeJS etc.

In simple terms reactive programming is about writing non blocking software that are asynchronous and event driven which require a small number of threads to scale vertically (Scale up inside a single JVM) instead of horizontally (Scale out to different nodes by means of clustering). 

If we take a look at the Spring Web MVC framework which was a Synchronous Blocking Framework based on Servlet (Prior to Servlet 3.x). Every Request Reaching a Spring Web MVC Controller would use the Request Thread that came a long with the Client Request to cater that request and will be blocking, Which meant that the scale-ability was bound to the maximum number of Request Threads a Web Container had. 

This was partially solved by the introduction of Servlet 3.x with asynchronous servlets where now a Request Thread would delegate the task of catering the request to a Separate Thread. Spring Web MVC framework allowed to return a DefferedResult from a Controller method which meant that the Request thread will not be blocking until the processing of the request by the Controller method.

Spring Web Flux uses a completely new approach of using Reactive Streams instead of the Servlet API. A key aspect of reactive is that it won't overwhelm the consumers when producers produce at a rate which is faster than the consumers can consume. This concept is called back pressure.

Reactive Programming will not let this happen (Image Courtesy : iStock)

References

1. https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/html/web-reactive.html
2. https://spring.io/blog/2017/05/08/spring-framework-5-0-goes-rc1