StackOverFlowError and memory leaking when sending large files slowly with Webflux + Undertow [SPR-16702]

[spring-projects-issues]

Napster opened SPR-16702 and commented

Experiencing a StackOverFlowException when serving a text/plain output with about 9k lines / total size of about 700kB in production.
Reproducing turns out to be a bit finicky. I provided sample code and a sample curl request below, but it might not trigger always and usually requires a lot more data attempted to be sent to be triggered in a test environment.

This is happening when using undertow with Spring Boot 2.0.0 and 2.0.1, with java 8 and java 9. Removing undertow (and using the default, which would be netty), it does not happen.

java.lang.StackOverflowError: null
	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:615) ~[undertow-core-1.4.23.Final.jar:1.4.23.Final]
	at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106) ~[undertow-core-1.4.23.Final.jar:1.4.23.Final]
	at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150) ~[xnio-api-3.3.8.Final.jar:3.3.8.Final]
	at io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:240) ~[undertow-core-1.4.23.Final.jar:1.4.23.Final]
	at io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:2094) ~[undertow-core-1.4.23.Final.jar:1.4.23.Final]
	at org.springframework.http.server.reactive.UndertowServerHttpResponse$ResponseBodyProcessor.writeByteBuffer(UndertowServerHttpResponse.java:196) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.UndertowServerHttpResponse$ResponseBodyProcessor.write(UndertowServerHttpResponse.java:176) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.UndertowServerHttpResponse$ResponseBodyProcessor.write(UndertowServerHttpResponse.java:147) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor$State$3.onWritePossible(AbstractListenerWriteProcessor.java:276) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.onWritePossible(AbstractListenerWriteProcessor.java:103) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.writeIfPossible(AbstractListenerWriteProcessor.java:212) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.access$300(AbstractListenerWriteProcessor.java:44) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor$State$3.onWritePossible(AbstractListenerWriteProcessor.java:294) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.onWritePossible(AbstractListenerWriteProcessor.java:103) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.writeIfPossible(AbstractListenerWriteProcessor.java:212) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.access$300(AbstractListenerWriteProcessor.java:44) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor$State$3.onWritePossible(AbstractListenerWriteProcessor.java:294) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.onWritePossible(AbstractListenerWriteProcessor.java:103) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.writeIfPossible(AbstractListenerWriteProcessor.java:212) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
	at org.springframework.http.server.reactive.AbstractListenerWriteProcessor.access$300(AbstractListenerWriteProcessor.java:44) ~[spring-web-5.0.5.RELEASE.jar:5.0.5.RELEASE]
.
.
.

curl -i -v -o /dev/null --limit-rate 1m localhost:8080/count?till=5000000

@RestController
public class TestController {

    @GetMapping("/count")
    public Mono<String> test(@RequestParam("till") long till) {
        return Mono.fromCallable(() ->
                count(till)
        );
    }

    private String count(long till) {
        StringBuilder sb = new StringBuilder();
        for (int ii = 0; ii < till; ii++) {
            sb.append(ii).append("\n");
        }
        return sb.toString();
    }
}

---

Affects: 5.0.5

Attachments:

• EPollSelectorImpl.png (139.41 kB)
• fullstacktrace.log (179.38 kB)

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

[spring-projects-issues]

Rossen Stoyanchev commented

Can you elaborate the "memory leaking" part? In the sample you're building the full String vs using something like Flux<String>.

[spring-projects-issues]

Rossen Stoyanchev commented

The underlying cause is similar to #21088. In this case on the write side, writeIfPossible is open to recursion since there is no good way to implement an isWritePossible check.

[spring-projects-issues]

Napster commented

Can you elaborate the "memory leaking" part?

Our application crashed due to running out of memory after a few hours and a total of about 5k StackOverflowErrors (as those reported above) thrown. In the heap dump we found references to EPollSelectorImpl after several full GCs, taking up huge amounts of memory:
!EPollSelectorImpl.png|thumbnail!

They held about 5k references to SelectionKeyImpl and SocketChannelImpl objects. Afaik those objects are used by undertow for its reactive magic. There were also references to about 5k lambdas of our MetricsController and RequestLogger classes, which are directly involved in handling the requests of the faulty endpoint, which I'm assuming stem from never being closed / freed due to the StackOverflowErrors.
Further evidence for the StackOverflowErrors and the memory leaks being related were JVM metrics reporting 6k open files, as opposed to about 1k normally, as well as the application not crashing due to running out of memory as soon as we replaced undertow with netty and the StackOverflowErrors stopped.
So I'm assuming that each StackOverflowErrors left some resources open. I'm not ruling out that this might be due to some weakness of our application design not handling Errors properly.

[spring-projects-issues]

Rossen Stoyanchev commented

This should be fixed now. It would be great if you could confirm with 5.1 or 5.0.6 snapshots.

[spring-projects-issues]

Napster commented

I cannot reproduce the issue anymore in a development environment with spring boot 2.1.0.BUILD-SNAPSHOT and spring-webflux 5.1.0.BUILD-SNAPSHOT (dependency snippet attached below for clarity).
Thank you for your work!

dependencies {
    compile("org.springframework.boot:spring-boot-starter-webflux:2.1.0.BUILD-SNAPSHOT")
    compile("org.springframework:spring-webflux:5.1.0.BUILD-SNAPSHOT")
    compile("org.springframework:spring-web:5.1.0.BUILD-SNAPSHOT")
    compile("org.springframework.boot:spring-boot-starter-undertow:2.1.0.BUILD-SNAPSHOT")
}

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for checking!