EofException, An established connection was aborted #544
Comments
|
This From your stacktraces, it appears to have occurred during a JSF write. This is not a bug in Jetty. This isn't even indicative of bad behavior anywhere. Some example scenarios (there are many scenarios for EofException): Scenario 1:
Scenario 2:
|
|
Note that if you are seeing this, then something is over logging. Jetty throws its own EofException rather than the container EOFException, so it can quietly log such common events. So what is logging this exception? |
|
If the client closes the connection after a response is committed but is closed before reading the entire response, jetty does an abort and there is no logging to identify the request as compared to the case when the response is completely sent and onCompleted() is called. Is there a way to add logging here? |
|
@tusharkarkera wrote:
You need to be more precise. Jetty may have already completely written the response, so from the Jetty point of view there is no error, no abort, just normal response handling. |
|
@sbordet Sorry about not clearly mentioning the problem. What I'm observing is that the client is trying to do a GET of a binary octet-stream(the contents of a SQLLite DB) into xmllint. The parse error expectedly caught by xmllint is breaking the pipe and causing curl to abort the HTTP request. HTTP client is resetting it's TCP connection with our server only after receiving a small amount of data. And I think the below trace is an indication of the fact that the response body content was unable to finish flushing to the network as the connection was terminated. Since the connection is terminated by jetty, I'm unable to have some kind of logging on the server side about the GET request that was made. I wanted to know if it's possible to gain back the control from jetty when the client abruptly terminates the connection. |
|
You don't show the whole stack trace (who calls Jersey), but it should be pretty easy to do a try/catch in your application and catch the exception that is thrown and unwinds from Jetty to Jersey to your application. The stack trace shows that a large write has been attempted and it caused TCP congestion. Since Jersey |
If a client drops the connection before a response was completely sent, Jetty will emit an `org.eclipse.jetty.io.EofException` which is then caught by Jersey. This can quite noisy in the logs and should typically be swallowed instead of logged including the stack trace. Refs #2482 Refs #2541 Refs jetty/jetty.project#544
If a client drops the connection before a response was completely sent, Jetty will emit an `org.eclipse.jetty.io.EofException` which is then caught by Jersey. This can quite noisy in the logs and should typically be swallowed instead of logged including the stack trace. Refs #2482 Refs #2541 Refs jetty/jetty.project#544
If a client drops the connection before a response was completely sent, Jetty will emit an `org.eclipse.jetty.io.EofException` which is then caught by Jersey. This can quite noisy in the logs and should typically be swallowed instead of logged including the stack trace. Refs #2482 Refs #2541 Refs jetty/jetty.project#544
If a client drops the connection before a response was completely sent, Jetty will emit an `org.eclipse.jetty.io.EofException` which is then caught by Jersey. This can quite noisy in the logs and should typically be swallowed instead of logged including the stack trace. Refs #2482 Refs #2541 Refs jetty/jetty.project#544
If a client drops the connection before a response was completely sent, Jetty will emit an `org.eclipse.jetty.io.EofException` which is then caught by Jersey and logged. This can quite noisy in the logs and should typically be swallowed instead of logged including the stack trace. The introduced `EofExceptionWriterInterceptor` will catch `EofException` which are being thrown while writing and will swallow them (after logging on DEBUG level). Refs #2482 Refs #2541 Refs jetty/jetty.project#544
If a client drops the connection before a response was completely sent, Jetty will emit an `org.eclipse.jetty.io.EofException` which is then caught by Jersey and logged. This can quite noisy in the logs and should typically be swallowed instead of logged including the stack trace. The introduced `EofExceptionWriterInterceptor` will catch `EofException` which are being thrown while writing and will swallow them (after logging on DEBUG level). Refs #2482 Refs #2541 Refs jetty/jetty.project#544 (cherry picked from commit 822f497)
Application runs on Windows and org.eclipse.jetty.io.EofException is appeared
What could be the cause and how to fix?
The text was updated successfully, but these errors were encountered: