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
UNDERTOW-2228 Undertow write-timeout can cause a truncate response for request coming through keep-alive connection #1475
Conversation
FYI @fl4via |
666072d
to
4e22132
Compare
Note: I didn't manage to reproduce the HttpContinueSslServletTestCase locally, even on JDK 17. I can see this failure in other PRs so I assume it's unrelated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will need to keep the old constructor as this is public API
c29e73c
to
c888a69
Compare
Thanks! I added the original constructor back. |
I can reproduce the Windows test freeze on a Windows VM easily, but so far didn't manage to do anything about it. Attaching stacktrace screenshot of where the test case gets stuck (didn't manage to get clipboard sharing working with the Windows VM :) ). At first sight it looks like the httpclient gets stuck when reading the response entity, but it could be caused by some discrepancy on undertow side I guess... |
This applies to scenarios like: * multiple HTTP requests over a single Keep-Alive connection, * JBoss remoting where multiple invocations come over single connection.
c888a69
to
eaf43f4
Compare
Hello @fl4via , the stuck Windows tests are gone. There is one failure in DefaultServletCachingListenerTestCase in the "Undertow CI / JDK 17 - servlet - ubuntu-latest" which looks unrelated to me. Locally is passing. |
Thanks @TomasHofman ! |
https://issues.redhat.com/browse/JBEAP-24358
https://issues.redhat.com/browse/UNDERTOW-2228
This change resets the expireTime variable in the
WriteTimeoutStreamSinkConduit at the end of each request. This should
prevent a subsequent request on the same connection to be affected by
timeout counter started during a previous request.