spring webflux ServerRequest.bodyToMono().block will freeze for HTTP post request whose header size + body size > 1024 [SPR-16579]

[spring-projects-issues]

Yang Wang opened SPR-16579 and commented

// curl -vX POST --data @large_file.txt http://localhost:8080/test
// if header + body > 1024, body.block() will freeze
@Bean
  public RouterFunction<ServerResponse> rf() {
    return route(
        POST("/test"), req -> {
          Mono<String> body = req.bodyToMono(String.class);
          System.out.println(body.block());
          return ServerResponse.ok().body(Mono.just("ok"), String.class);
        }
    );
  }

---

Affects: 5.0.4

Issue Links:

• StackOverflowError when using WebFlux multipart file data handler with Undertow [SPR-16545] #21088 StackOverflowError when using WebFlux multipart file data handler with Undertow
• Webflux server sometimes block when receiving large post body [SPR-16209] #20757 Webflux server sometimes block when receiving large post body ("supersedes")

1 votes, 4 watchers

[spring-projects-issues]

Brian Clozel commented

What Reactor Netty version are you using?
This looks a lot like this Reactor Netty issue that was solved recently (in 0.7.5.RELEASE).

Could you try the following commands and let me know about the result?

curl -vvX POST --data @large_file.txt http://localhost:8080/test

curl -vvX POST --header "Expect:" --data @large_file.txt http://localhost:8080/test

Thanks!

[spring-projects-issues]

Yang Wang commented

The latest boot release version

[spring-projects-issues]

Brian Clozel commented

Could you answer my other questions as well?

[spring-projects-issues]

Yang Wang commented

I will update with details a moment later.

[spring-projects-issues]

Yang Wang commented

$ curl -vvX POST --data @large_file.txt http://localhost:8080/test
Note: Unnecessary use of -X or --request, POST is already inferred.
* STATE: INIT => CONNECT handle 0x456f160; line 1392 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x456f160; line 1428 (connection #0)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x456f160; line 1509 (connection #0)
* Connected to localhost (::1) port 8080 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x456f160; line 1561 (connection #0)
* Marked for [keep alive]: HTTP default
* STATE: SENDPROTOCONNECT => DO handle 0x456f160; line 1579 (connection #0)
> POST /test HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Length: 4088
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* STATE: DO => DO_DONE handle 0x456f160; line 1658 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x456f160; line 1783 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x456f160; line 1799 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 100 Continue
} [4088 bytes data]
* We are completely uploaded and fine
100  4088    0     0  100  4088      0    398  0:00:10  0:00:10 --:--:--     0

[spring-projects-issues]

Yang Wang commented

$ curl -vvX POST --header "Expect:" --data @large_file.txt http://localhost:8080/test
Note: Unnecessary use of -X or --request, POST is already inferred.
* STATE: INIT => CONNECT handle 0x267f160; line 1392 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x267f160; line 1428 (connection #0)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x267f160; line 1509 (connection #0)
* Connected to localhost (::1) port 8080 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x267f160; line 1561 (connection #0)
* Marked for [keep alive]: HTTP default
* STATE: SENDPROTOCONNECT => DO handle 0x267f160; line 1579 (connection #0)
> POST /test HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Length: 4088
> Content-Type: application/x-www-form-urlencoded
>
} [4088 bytes data]
* upload completely sent off: 4088 out of 4088 bytes
* STATE: DO => DO_DONE handle 0x267f160; line 1658 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x267f160; line 1783 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x267f160; line 1799 (connection #0)
100  4088    0     0  100  4088      0    563  0:00:07  0:00:07 --:--:--     0

[spring-projects-issues]

Yang Wang commented

component version:
Spring Boot :: (v2.0.0.RELEASE)
io.projectreactor.ipc:reactor-netty:0.7.5.RELEASE

[spring-projects-issues]

Rossen Stoyanchev commented

This looks like a duplicate of #20757. The default assumption in a WebFlux application is that there will be no blocking.

That said for a single request it probably shouldn't hang. A follow-up improvement for reactor/reactor-netty#293 might be needed. My guess is that the blocking prevents Reactor Netty from responding, so let's see where reactor/reactor-netty#305 goes.

[spring-projects-issues]

Brian Clozel commented

In the meantime Yang Wang, you can use the following code snippet works and is more in line with what's expected from a reactive application.

@Bean
public RouterFunction<ServerResponse> rf() {
	return route(
		POST("/test"), req -> {
			return req.bodyToMono(String.class)
			.doOnNext(body -> System.out.println(body))
			.then(ServerResponse.ok().body(Mono.just("ok"), String.class));
		}
	);
}

[spring-projects-issues]

Oleg Schelykalnov commented

It looks like applications based on RestController affected too.

[spring-projects-issues]

Brian Clozel commented

I'm closing this issue as it's mainly duplicating other issues in Spring Framework and Reactor Netty that are now solved.

If you still face this problem, please reopen this issue with a sample application that consistently reproduce the problem.

Thanks!

[spring-projects-issues]

Rossen Stoyanchev commented

Effectively this issue superseded by Reactor Netty #305 which reproduces the same issue without WebFlux.

[spring-projects-issues]

Oleg Schelykalnov commented

There is a example project: https://github.com/olegshtch/webflux-security
I've tested it with glassfish 5.0.0

Test query:

curl -X POST http://127.0.0.1:8080/test/api/login -v -H "Content-Type: application/json" -d "{}"

[spring-projects-issues]

Brian Clozel commented

This looks like a totally different issue - the request body you're suggesting here is not > 1024.
Have you tried deploying the same application on a different server (Tomcat or Jetty?).

[spring-projects-issues]

Oleg Schelykalnov commented

Yep, it works under Tomcat.

[spring-projects-issues]

Rossen Stoyanchev commented

Fresh ticket and description please