AsyncContext completion attempt after AsyncListener.onError is called #5675
Comments
|
@lorban anything else to add here? |
|
@wendigo no; you accurately described the problem. |
|
It looks like creating the test case is the most difficult part here |
|
@jansupol is there a plan to fix this issue? |
|
Yes, we plan to check on the possibilities for this. |
|
I don't know about this part but I would like to take a look. My understanding is that the issue is happening in the server side. The server receives Are you able to print the stacktrace when |
|
Actually async context can complete with error on a different thread than the competing thread that will try to complete with a result. It seems that this isn't synchronized in any way. |
|
In Jetty it's pretty visible because when the context is completed (successfully or not) the resources are recycled which causes errors to be logged (request/response doesn't exist) |
Here you go, this is the stacktrace received by In this case, the EOF results in a completed (and set to committed) response (if not completed yet). |
|
Also note that Jersey works with the behaviors of the Servlet spec. That means the HttpServletRequest / HttpServletResponse objects can be reused / recycled for other requests / responses. |
|
I am reproducing it in |
|
I found that the exception was not re-throw because the response was already committed. I have modified the code, so if the exception is instance of IOException, we still throw it up so the container can do something. Now the exception reaches the Jetty container (as you can see in the next screenshoot) but I am having questions about whether it is going to reuse request/response objects or not. Maybe you can help me with this verification, I will write instructions soon.
|
jbescos
added a commit
to jbescos/jersey
that referenced
this issue
Oct 18, 2024
…clipse-ee4j#5675 Signed-off-by: Jorge Bescos Gascon <[email protected]>
|
@wendigo could you help me to verify the fix?. Although I am trying to help, I am not expert in this area. Could you overwrite the class inside the zip under |
|
Hi Jetty experts!, did any of you have a chance to verify the fix?. |
jbescos
added a commit
to jbescos/jersey
that referenced
this issue
Oct 29, 2024
…clipse-ee4j#5675 Signed-off-by: Jorge Bescos Gascon <[email protected]>
jbescos
added a commit
to jbescos/jersey
that referenced
this issue
Oct 29, 2024
…clipse-ee4j#5675 Signed-off-by: Jorge Bescos Gascon <[email protected]>
jbescos
added a commit
to jbescos/jersey
that referenced
this issue
Oct 30, 2024
…clipse-ee4j#5675 Signed-off-by: Jorge Bescos Gascon <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've observer an issue with Jersey 3.1.+ running in the Jetty EE10 container that applies to HTTP/2 protocol.
When client disconnects in the middle of the request (due to a timeout or whatever), it sends a RST_STREAM frame that on the server side, finishes an AsyncContext with an error through the AsyncListener.onError. It seems that Jersey doesn't understand this condition, and still tries to finish an AsyncContext when the AsyncResponse.complete is called. Since Jetty recycles request/response objects on AsyncContext error, there is no response to write output to, and the jersey code generates a non-actionable warning.
We've work around this issue by implementing trinodb/trino#22315 that seems to do a trick. I'd like to see a permanent solution on the Jersey side instead.
The text was updated successfully, but these errors were encountered: