-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Jetty 12 - LargeHeaderTest
shows rare (error) response write bug where no response is produced
#9672
Comments
@sbordet I managed to capture a full DEBUG log from this branch. (had to turn on logback to capture it successfully). Pay attention to the end of the log.
|
@gregw you might want to be aware of this |
@joakime can you still reproduce this? |
I get a long pause every 500 to 1000 runs when running in a loop in Intellij, but the test does not fail. No reports of empty responses and when a test for slow responses is added, I see no slow responses? |
Hmmmm when I stop the test in the middle of a long pause and then immediately re-run it, then very first test goes back into a long pause. Thus I'm thinking it is an intellij or system issue rather than a test issue. |
I consider this to be fixed by PR #9684 now |
Jetty version(s)
12
Java version/vendor
(use: java -version)
17.0.6
OS type/version
Linux
Description
When working on restoring the disabled test
LargeHeaderTest
it can be seen that some of the responses are not producing any response.The connection is closed before a response is written (as evidenced by wireshark capture).
It happens about 1 time out of 200 full requests.
See branch
fix/12.0.x/large-header-test
for the current state of theLargeHeaderTest
.Note: the
LargeHeaderTest
creates 500 new connections, each making a simple request, every request reaches the Handler, which adds an excessively large response header, and then attempts to write a tiny response body. Each response that the client sees should be a500: Response header too large
.The text was updated successfully, but these errors were encountered: