-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spring Webflux. Memory leak. #27965
Comments
I found one more interesting effect. If I add to the second part of code GET("/test") {
operationRepository.findOperationsRangeForCarrier(carrierIds, start, end) // returns about 800_000 items
.map { writer.writeValueAsBytes(it) }
.reduce(ByteArrayOutputStream()) { output, el ->
output.write(el)
output
}
.map { output -> output.toByteArray() }
.doOnNext { println("report size ${it.size}") }// 229Mb
.subscribe()
ServerResponse.ok().bodyValue("OK")
} |
It's not immediately obvious how What is the underlying HTTP server for this? Any chance of a repro project? |
I created a simple project to reproduce memory leak: https://github.com/typik89/webfluxMemoryRetroProject. To run a database locally before starting the application, use https://github.com/typik89/webfluxMemoryRetroProject/blob/main/src/main/resources/docker-compose.yml. After starting the application use requests HTTP GET http://localhost:8080/test to reproduce. As a result of requests, It should be downloaded files with a size of about 70MB. If you make a heap dump, you will see that all byte arrays are live objects in Heap and they will acummulate in heap while OOM happens. |
Thanks for the sample. Docker compose doesn't start, complains about the image. For the sake of simplicity, can the issue be reproduced without a data layer. A repository that simply returns fake data maybe? |
Sorry, I changed to 'image: postgres:13-alpine'.
And I don't see memory leaking in this case |
@rstoyanchev I migrate the sample to Java in order to allow you to validate it is not related to our Kotlin integration. |
I've tried with Java and seen the same |
It seems that it's not a webflux issue. |
It might make more sense for this issue to be in https://github.com/reactor/reactor-core/issues, but it cannot be transferred across organizations. I'm going to close this as it does not seem like anything we can fix in the Spring Framework, but more comments welcome, once you find out more about the root cause. /cc @simonbasle |
Affects: 2.3.1.RELEASE
I found that spring webflux doesn't allow gc to collect a garbage.
I simplified my code. There is simple pipeline:
The result file is downloaded successfully and has a size about 229Mb.
After several sequential requests I found that the memory wasn't released and in result I had OOM.
Heap dump showed that the result byte arrays are live objects and GC can't collect them because they have GC root
WindowsSelectorImpl
.Interesting that if I modify my code:
I see that file is creating. but after process of creating is finished, heap dump doesn't contain resulted bytearray.
I conclude that the main reason for the leak is spring webflux and not project reactor.
Maybe something must be configured differently
The text was updated successfully, but these errors were encountered: