-
Notifications
You must be signed in to change notification settings - Fork 38.4k
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
Issue got on server #26607
Comments
Could you provide us with a repro project for this, without involving the Thanks! |
Apologies, I cannot provide the repo of the project, since it belongs to the organization The repository As per the exception log, the issue is not originating at the organization project, but coming from within netty |
Due to the asynchronous nature of request/response handling, the stacktrace doesn't necessarily means that the issue is in Netty or Spring Framework. A simple repro project is essential here and we can't really help. There might be an issue with the interceptor implementation, or maybe the HTTP client closed the connection before the server could write the entire response. Let us know if you manage to get to a sample that we can use. Thanks! |
I am not sure how I can share the whole project with you, since it belongs to the organization I work with If you can let me know, exactly what you are looking for, code snippet or fragment, perhaps I should be able to help you with it From the exceptions, it is showing only the cause, and not the exceptionTraceHeirarchy of the actual exception We have also encountered the following exceptions several time, which neither have the exceptionTraceHeirarchy nor cause :-
and
Also kindly let me know if anything can be done from my end, or it is something which needs to be looked into from Spring side, or if it is expected behaviour which should not be handled |
I'm not asking for a full project - if you believe this is an issue in Spring Framework, trying to narrow down the problem by removing behavior and dependencies from the app (or starting with a new app from start.spring.io and slowly introducing changes until you can reproduce it) is really important. The exceptions seem to indicate that the client has closed the connection prematurely - there's nothing the server can do here, besides report an exception. Depending on the server, we're trying to catch those exceptions at the handler level and log them in a dedicated group. Since your filter is listening to all signals and gathering information about them (and since the filter is a lower level construct), it might be expected to get those at this level. Now without knowing what's the behavior of the client, it's hard to figure out if this is the expected behavior because the client is closing the connection prematuerly, or if it's a bug in the filter/interceptor because it might be using resources outside of their expected lifecycle (writing/reading from the exchange after it's done), or an actual bug in Spring Framework or Reactor Netty. Issues like #26232 or #26181 or even spring-projects/spring-boot#23606 show that it's sometimes hard to come up with proper repro projects for such precise behaviors, but maybe the repros provided there can help. |
From a quick glance, could it be the client closed the connection after the response was committed and writing was in progress but before it was finished? You have not indicated versions for Reactor Netty and Spring Framework so it's hard to tell much. You might want to look in the Reactor Netty source code and version you have to see in what cases that |
Spring framework version is 2.1.7.RELEASE OutOfMemoryError does sound like a logical explanation, has happened in the past, had to optimize the interceptor then |
getting the following exception on server, when using webflux
happened for 7 api calls (request-response)
encountered the issue 14 times within 2 minutes
these were thrown twice for the same api request-response exchange, the turnaround frame of this one was 150ms
but the request-response transition details were as follows
using the following dependencies to be precise
The text was updated successfully, but these errors were encountered: