WebClient: NPE and leak in case connection is reset by server. #25216
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Thanks for the reproducer! The NPE is a Reactor Core issue for which I've created reactor/reactor-core#2186. Still looking and also need to check the impact of that fix. |
|
@EtienneMiret I think we've found the the issue for this sample. Using a local fix for reactor/reactor-netty#1161 along with reactor/reactor-core#2186 I see no more leak reports with the sample. Once there is a snapshot available with a fix for the Reactor Netty issue, perhaps you can give it a try? I will keep this issue open until then. |
|
@rstoyanchev Thank you so much. I’ll have a look at those fixes. |
rstoyanchev
added
in: web
|
This is going to be fixed in Spring Framework after all. What happens is that when batches of 50 requests are send concurrently with |
|
@EtienneMiret when you have a chance, please give 5.2.8 snapshots a try and you'll also need reactor-core 3.3.7 snapshots for the NPE. |
|
Hi @rstoyanchev. Thanks for the fix. I can confirm that my sample runs smoothly with My real app still has OOM errors, but since it doesn’t log |
|
Thanks, let us know if you find anything further on our side. |
The following was reported after the change and is related to it: reactor/reactor-netty#1170. An HTTP HEAD with the body not consumed. Connection is disposed and closed leading to subsequent request to fail. Adding toBodilessEntity() helps. This change does not close the connection but rather drains the body which does not impact subsequent re-use of the connection. This however may compete with a late subscriber actually attempting to read the response. At that point there is little choice but to raise an ISE with a more specific description. See gh-25216
The following was reported after the change and is related to it: reactor/reactor-netty#1170. An HTTP HEAD with the body not consumed. Connection is disposed and closed leading to subsequent request to fail. Adding toBodilessEntity() helps. This change does not close the connection but rather drains the body which does not impact subsequent re-use of the connection. This however may compete with a late subscriber actually attempting to read the response. At that point there is little choice but to raise an ISE with a more specific description. See spring-projectsgh-25216
Affects: 5.2.7.RELEASE
I’m having a memory leak in a real application, which I tried to reproduce with the sample: https://github.com/EtienneMiret/reactor-netty-oom.
In this sample, having a flux of integers, I call the below method on each of them and then aggregate the results:
When the server is behaving properly, all is fine, but in case it aborts the TCP connection, this code starts leaking memory. My bet is that the network error triggers an exception which cancels the Flux, thus preventing the
response -> response.bodyToMono (ByteArrayResource.class)lambda from being called. The.delayElement ()operator is an attempt at making it more likely that the ClientResponse is built and not consumed.If I understand properly ClientResponse’s Javadoc and #21801, my code is correctly consuming the response, and error cases (such as IO error or pipeline cancellation) should be handled by Spring. Is this indeed the case?
After the first connection reset from the server, I have the below stack:
And later (when the GC runs I guess), I have a number of:
See full error.log.
I’m still not sure where the issue is (my code? Spring? Reactor-netty?). Sorry if this turns out not to be a Spring bug.
The text was updated successfully, but these errors were encountered: