{"id":59765,"date":"2020-08-23T16:26:02","date_gmt":"2020-08-23T16:26:02","guid":{"rendered":"https:\/\/www.baeldung.com\/?p=86095"},"modified":"2020-08-23T16:26:02","modified_gmt":"2020-08-23T16:26:02","slug":"spring-mvc-async-vs-spring-webflux","status":"publish","type":"post","link":"https:\/\/itteacheritfreelance.hk\/wordpress\/index.php\/2020\/08\/23\/spring-mvc-async-vs-spring-webflux\/","title":{"rendered":"Spring MVC Async vs Spring WebFlux"},"content":{"rendered":"

<\/p>\n

1. Introduction<\/h2>\n
<\/div>\n

In this tutorial, we’ll explore the @Async<\/em> annotation in Spring MVC, and then we’ll get familiar with Spring WebFlux. Our goal is to have a better understanding of the difference between these two.<\/p>\n

2. Implementation Scenario<\/h2>\n
<\/div>\n

Here, we want to choose a scenario to show how we can implement a simple web application with each of these APIs. Moreover, we’re especially interested to see more about thread management and blocking or non-blocking I\/O in each case.<\/p>\n

Let’s choose a web application with one endpoint that returns a string result. The point here is that the request will pass through a Filter<\/em> with a small 200ms delay, and then the Controller<\/em> needs 500ms to calculate and return the result.<\/p>\n

Next, we’re going to simulate a load with Apache ab<\/a> on both endpoints and monitor our app behavior with JConsole<\/a>.<\/p>\n

It may worth mentioning that in this article, our goal is not a benchmark between these two APIs, just a small load test so we can trace the thread management<\/strong>.<\/p>\n

3. Spring MVC Async<\/h2>\n
<\/div>\n

Spring 3.0 introduced the @Async<\/em> annotation. @Async<\/em>‘s goal is to allow the application to run heavy-load jobs on a separate thread. Also, the caller can wait for the result if interested. Hence the return type must not be void<\/em>, and it be can be any of Future<\/em><\/a>, CompletableFuture<\/em><\/a>, or ListenableFuture<\/em>.<\/p>\n

Moreover, Spring 3.2<\/a>\u00a0introduced the org.springframework.web.context.request.async<\/em> package that, together with Servlet 3.0<\/a>, brings the joy of the asynchronous process to the web layer. Thus, since Spring 3.2, @Async<\/em> can be used in classes annotated as @Controller<\/em> or @RestController<\/em>.<\/p>\n

When the client initiates a request, it goes through all matched filters in the filter chain until it arrives at the DispatcherServlet<\/em> instance.<\/p>\n

Then, the servlet takes care of the async dispatching of the request. It marks the request as started by calling AsyncWebRequest#startAsync, <\/em>transfers the request handling to an instance of WebSyncManager<\/em>, and finishes its job without committing the response. The filter chain also is traversed in the reverse direction to the root.
\n
\n<\/em><\/p>\n

WebAsyncManager<\/em> submits the request processing job in its associated ExecutorService<\/em>. Whenever the result is ready, it notifies DispatcherServlet<\/em> for returning the response to the client.<\/p>\n

4. Spring Async Implementation<\/h2>\n
<\/div>\n

Let’s start the implementation by writing our application class, AsyncVsWebFluxApp<\/em>. Here, @EnableAsync<\/em> does the magic of enabling async for our Spring Boot application:<\/p>\n

@SpringBootApplication\r\n@EnableAsync\r\npublic class AsyncVsWebFluxApp {\r\n    public static void main(String[] args) {\r\n        SpringApplication.run(AsyncVsWebFluxApp.class, args);\r\n    }\r\n}<\/code><\/pre>\n
Then we have AsyncFilter<\/em>, which implements javax.servlet.Filter. <\/em>Don’t forget to simulate the delay in the doFilter<\/em> method:<\/p>\n
@Component\r\npublic class AsyncFilter implements Filter {\r\n    ...\r\n    @Override\r\n    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)\r\n      throws IOException, ServletException {\r\n        \/\/ sleep for 200ms \r\n        filterChain.doFilter(servletRequest, servletResponse);\r\n    }\r\n}<\/code><\/pre>\n
Finally, we develop our AsyncController<\/em> with the “\/async_result<\/em>” endpoint:<\/p>\n
@RestController\r\npublic class AsyncController {\r\n    @GetMapping(\"\/async_result\")\r\n    @Async\r\n    public CompletableFuture getResultAsyc(HttpServletRequest request) {\r\n        \/\/ sleep for 500 ms\r\n        return CompletableFuture.completedFuture(\"Result is ready!\");\r\n    }\r\n}<\/code><\/pre>\n
Because of the @Async<\/em> above getResultAsync<\/em>, this method is executed in a separate thread on the application’s default ExecutorService<\/em><\/a>. However, it is possible to set up a specific ExecutorService<\/em> for our method<\/a>.<\/p>\n
Test time! Let’s run the application, install Apache ab, or any tools to simulate the load. Then we can send a bunch of concurrent requests over the “async_result” endpoint. We can execute JConsole and attach it to our java application to monitor the process:<\/p>\n
ab -n 1600 -c 40 localhost:8080\/async_result<\/code><\/pre>\n
 <\/p>\n
\"\"<\/a> \"\"<\/a><\/p>\n
5. Spring WebFlux<\/h2>\n
<\/div>\n
Spring 5.0 has introduced WebFlux to support the reactive web<\/a> in a non-blocking manner. WebFlux is based on the reactor API, just another awesome implementation of the reactive stream<\/a>.<\/p>\n
Spring WebFlux supports reactive backpressure and Servlet 3.1+<\/a> with its non-blocking I\/O. Hence, it can be run on Netty, Undertow, Jetty, Tomcat, or any Servlet 3.1+ compatible server.<\/strong><\/p>\n
Although all servers don’t use the same thread management and concurrency control model, Spring WebFlux will work fine as long as they are supporting non-blocking I\/O and reactive backpressure.<\/p>\n
Spring WebFlux allows us to decompose the logic in a declarative way with Mono, Flux,<\/em> and their rich operator sets. Moreover, we can have functional endpoints besides its @Controller<\/em> annotated ones.<\/p>\n
6. Spring WebFlux Implementation<\/h2>\n
<\/div>\n
For WebFlux implementation<\/a>, we go the same path as async. So at first, let’s create the AsyncVsWebFluxApp<\/em>:<\/p>\n
@SpringBootApplication\r\npublic class AsyncVsWebFluxApp {\r\n    public static void main(String[] args) {\r\n        SpringApplication.run(AsyncVsWebFluxApp.class, args);\r\n    }\r\n}<\/code><\/pre>\n
Then let’s write our WebFluxFilter<\/em>, which implements WebFilter.<\/em> We’ll generate an intentional delay and then pass the request to the filter chain:<\/p>\n
@Component\r\npublic class WebFluxFilter implements org.springframework.web.server.WebFilter {\r\n    @Override\r\n    public Mono filter(ServerWebExchange serverWebExchange, WebFilterChain webFilterChain) {\r\n        return Mono\r\n          .delay(Duration.ofMillis(200))\r\n          .then(\r\n            webFilterChain.filter(serverWebExchange)\r\n          );\r\n    }\r\n}<\/code><\/pre>\n
At last, we have our WebFluxController<\/em>. It exposes an endpoint called “\/flux_result”<\/em> and returns a Mono<String><\/em> as the response:<\/p>\n
@RestController\r\npublic class WebFluxController {\r\n    @GetMapping(\"\/flux_result\")\r\n    public Mono getResult(ServerHttpRequest request) {\r\n       return Mono.defer(() -> Mono.just(\"Result is ready!\"))\r\n         .delaySubscription(Duration.ofMillis(500));\r\n    }\r\n}<\/code><\/pre>\n
For the test, we’re taking the same approach as with our async sample application. Here’s the sample result for:
\n
\n<\/em><\/p>\n
ab -n 1600 -c 40 localhost:8080\/flux_result<\/code><\/pre>\n
\"\"<\/a>\"\"<\/a><\/p>\n
7. What’s the Difference?<\/h2>\n
<\/div>\n
Spring Async supports Servlet 3.0 specifications, but Spring WebFlux supports Servlet 3.1+. It brings a number of differences:<\/p>\n