We had a big fight finding a problem of Connection Prematurely Closed. We had a Producer which provided a Flux and the consumer was quite slow. After 60s the Flux showed a cancel event, because internally it got a SocketTimeout Exception which was not shown in info/warn log. Fix for us in this case was to increase the connection-timeout. To find that our producer had an internal timeout issue was quite hard, so I would propose to be more verbose on SocketTimeouts on supplied Flux streams.
Comment From: rstoyanchev
The description is ambiguous since there are different places in the framework it could be referring to. Please, provide sample usage so we can review this in more detail.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: Richie94
We just had a simple Restendpoint like from the producer like this with a Spring Boot 2.5.7 and Tomcat running.
@GetMapping(...)
fun returnFlux(...) : Flux<String>
....
And our consumer same Spring Boot 2.5.7 calling this endpoint with a Webflux Webclient. When the request for the next element in our client took longer than 60s, in our client we received an PrematurCloseException and in the producer the onCancel Event was fired without the information, that it was the internal decision of the producer to cancel this thing due to a timeout. Im not right sure where it would be placed best, but I wished that the cancel event would be more descriptive so I would know faster: the cancel decision came from an internal timeout because of tomcat timeouts.
Comment From: rstoyanchev
The overall scenario is more clear now. On Servlet containers in WebFlux, however, we call AsyncContext.setTimeout(-1)
, i.e. the socket should never time out. So it's not clear what's causing the connection to close and that makes it challenging to think about where to add logging.
Have you tried putting log statements in a WebFilter
to determine what leads to the connection getting closed? If you are able to provide something that simulates the issue, we can also also take a look.
Comment From: Richie94
I tried to supply a minimal example, as I think now it may not be the desired behaviour as it is right now. I have there a quite simple setup, where I just wait some time after buffering, and after 30s this crashes. Here I just call the "consume" endpoint which requests via a webclient the other producing endpoint and after 30s I see this cancel event occurring. I simulate here, that the consumer does some batch processing where each batch takes 90s and avter each batch, the consumer asks the producer for the next batch so. This is with current 2.6.7 spring boot including spring-web (for tomcat) and spring-web-reactive (for having the fluxes).
https://pastebin.com/ewMM9nTV
Comment From: snicoll
@Richie94 I've tried to paste that in an actual project and that didn't reproduce the issue. Rather than a paste of code in text, can you please share a project we can run ourselves? You can attach a zip to this issue or push the code to a separate GitHub repository. Thank you.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.