DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Frameworks
  4. Understanding Spring Reactive: Introducing Spring WebFlux

Understanding Spring Reactive: Introducing Spring WebFlux

Want to learn more about using Spring Reactive? In this part of the Spring Reactive series, we look at using Spring WebFlux, the Spring Reactive stack.

Naveen Katiyar user avatar by
Naveen Katiyar
·
Oct. 03, 18 · Presentation
Like (17)
Save
Tweet
Share
55.74K Views

Join the DZone community and get the full member experience.

Join For Free

In this article, we are going to discuss the different choices provided by Spring 5 for the Reactive and Async concurrency model. I strongly believe that, before we embrace something new, we should be aware of the differences between choices and how it connects to what we have been already doing. In my previous articles on this topic, I have tried to explain what we already have regarding the concurrency model and how the concurrency model has changed in Spring over the years, with several updates in Servlet APIs. I would strongly recommend reading my previous articles on this topic so that this article will make more sense!

Let’s try to figure out what was the reason to provide two different non-blocking stacks in Spring 5. Basically, Spring 5 provides the following two stacks for doing things in Async and a non-blocking way:

  1. Spring MVC (Servlet Stack)
  2. Spring WebFlux(Reactive Stack)

Spring MVC (Servlet Stack)

With the introduction of Servlet 3.1, Spring MVC could achieve non-blocking behavior. But, as the Servlet API contains several interfaces that are still blocking (maybe because of support for backward compatibility), there was always the chance of accidentally using blocking APIs in the application, which was intended to be developed as non-blocking. In such scenarios, the usage of a blocking API will certainly bring down the application sooner or later. Let’s discuss one such scenario with the code snippet below:

void onWritePossible(){
  try{
     //some logic here
  }catch(Exception e){
     response.sendError(500); ----> sendError() is a blocking API
  }
}


To explain the above code in Spring MVC context, using the container-managed error page is blocking. Let’s take a look at the code on my GitHub repository.

@Controller
public class MyErrorController implements ErrorController {
    @RequestMapping(path = "/error")
    public String greeting() {
        return "myerror";
    }
    @Override
    public String getErrorPath() {
        return "/error";
    }
}


Whenever an error occurs in a Spring application, the container would invoke the  /error  page, and the ‘myerror’ page would be rendered in a blocking way. Off course, we have ways to handle such things, but they are definitely error-prone. To summarize, this is error-prone, because the application has access to the Servlet object, which has both blocking and non-blocking operations as shown below:

Flow Of Events

So, even though we have ways in Spring 5 MVC to write completely non-blocking code, the need was felt to have a stack in which there are no chances that an underlying, blocking API could be used. This means that the Servlet API is not directly exposed to the application. This forces us to incorporate the Spring Reactive stack, i.e. Spring WebFlux.

Spring WebFlux (Reactive Stack)

Spring WebFlux is a completely non-blocking reactive framework, and it is indeed different than what we have in Spring MVC. So, what does it take to not block in the Spring WebFlux:

  • Event Loop at the core.
  • Event-driven architecture, message passing
  • Means to compose Async logic through the Reactive Streams API
  • Backpressure

As we can see in the diagram below, Spring WebFlux does not directly use the Servlet. Instead, it uses the Spring Web API, which includes Reactor Streams.

The purpose of this series is to demonstrate the evolution of the Servlet/Spring from the blocking to non-blocking paradigm. I am not going into the details of Spring WebFlux in this tutorial. But, still, I am going to introduce a sample Spring Boot application using Spring WebFlux.

One point which we should notice in the above diagram is that Spring WebFlux is Servlet Container agnostic. Spring Webflux works on Servlet Container and also on Netty through Reactor Netty Project.


In my Spring boot application, I have a dependency on WebFlux as spring-boot-starter-webflux, and at server startup, it says that the application is ready with Netty.

[reactor-http-nio-1] 18:33 BlockingNettyContext: Started HttpServer on /0:0:0:0:0:0:0:0:8080

[restartedMain] 18:33 NettyWebServer: Netty started on port(s): 8080


In the same application, if we use dependency for the spring-boot-starter-web, then logs would be printed as shown below:

[restartedMain] 23:56 TomcatWebServer: Tomcat started on port(s): 8080 (http) with context path ''


So, without any code change, we can run the Spring WebFlux application as a Spring MVC application. But, vice-versa is not true as the Spring MVC application could be using the  HttpServletRequest/Response, which is not available in Spring WebFlux runtime.

I have created the same type of service that we used in an earlier article with WebFlux, as shown below:

@GetMapping(value = "/reactiveService")
public Mono<String> reactiveService(){
    logger.debug("reactiveService Request processing started");
    return webClient.get().uri("/sleep/1000")
            .retrieve().bodyToMono(Boolean.class)
            .doOnNext(response->{ logger.debug("reactive service");})
            .then(Mono.just("reactiveService"));
}


I would leave this for readers to compare the performance between this API and the  asyncNonBlockingRequestProcessing API, as both are using the non-blocking paradigm, but the underlying stack is different for both APIs.

Thank you for reading my article, and I hope it helps a bit in understanding Reactive in the Spring/Servlet context.

The source code for this post can be found on GitHub.

Spring Framework application

Published at DZone with permission of Naveen Katiyar, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Why It Is Important To Have an Ownership as a DevOps Engineer
  • Distributed Stateful Edge Platforms
  • Best Practices for Writing Clean and Maintainable Code
  • Memory Debugging: A Deep Level of Insight

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: