[jetty-dev] Re: Cometd build problem: Found

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Simone (cc jetty-dev@eclipse)

I think the exceptions that I am concerned about are already wrapped.
So we should be able to better detect them.

But if we are sending 500 and closing, we should also add the
close connection header.

I'll have a look this morning.

But also note that a server is entitled to close a connection
at anytime after sending a legal HTTP/1.1 response.   So the
client should detect the close and handle it.  Failing that,
when it goes to reuse it, and it fails - that should be
handled and a new connection used (clients are hard!).

Which client is this? Is this just your test client?

cheers



Simone Bordet wrote:
> Greg,
> 
> I found the problem related to the Cometd build failing. The build
> passes with RC4 and fails starting with RC5 onwards.
> 
> The cometd test does this: installs a servlet filter that throws for
> every request after the bayeux handshake.
> When the connect comes, it throws and jetty replies with a 500. The
> exception thrown lands in ServletHandler where in RC4 was eaten and
> ignored, while in RC5 is rethrown (lines 518-519).
> This change has been made by you in revision 753 with this comment:
> "JETTY-1086 Added UncheckedPrintWriter to avoid ignored EOFs".
> 
> Rethrowing the exception ends up in HttpConnection that decides that
> since there's an exception it's better to close the endpoint.
> However, the response to the client does not contain the "Connection:
> close" header, so the client thinks the connection is still good, and
> reuses it to fail just afterwards because the endpoint is closed.
> This is confirmed by wireshark where for RC5 I see a FIN sent by the
> server, no FIN sent by the client, who sends data to the server on the
> same connection, which triggers a RST.
> 
> Now there are several ways to fix it:
> 1. Make sure that every time we send a 500, we close the connection,
> and we add the "Connection: close" header.
> 2. Rework the ServletHandler change, but not sure how one can
> distinguish between ignored EOF and IOExceptions throws by a user
> servlet/filter.
> 3. Have the client retry automatically if it detects that the endpoint
> is closed.
> 
> There may be other ways, but I'm not sure what is best and what
> exactly you tried to fix with rev. 753 wrt EOFs.
> 
> A suggestion: will be quite easy to detect exceptions thrown by user
> code, and we could wrap them into a special exception, say
> UserException, which we handle carefully in the code.
> This way we know for sure if it's Jetty generating IOExceptions, or if
> it's the user (and HttpConnection would not confuse a user IOException
> which already generated a 500 response from a Jetty IOException that
> would require the endpoint to be closed).
> 
> Let me know what you think.
> 
> Cheers,
> 
> Simon