[
https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088651#comment-15088651
]
Greg Wilkins commented on SOLR-8453:
------------------------------------
Ah - well I've evolved my view a bit, although the client (as in the part that
uses the HttpClient) may need to be fixed.
To repeat what I stated on the jetty-user list, I think both client and server
are acting reasonably. Jetty sees an application return without having
consumed all of a request - it assumes this is an error condition, makes a best
effort attempt to consume, but when that requires blocking decides to close the
connection before all the content is sent.
The HttpClient is sending a chunked body and the connection is closed before it
sends the terminal chunk, so apache is correct to return an exceptional
condition to the client application, as the request did not end correctly. I
guess the HttpClient could potentially do better by making the status received
in the response available, but then it is in a race because the close may occur
prior to the response being read/parsed/processed.
So if the client applications cannot be made more robust - ie it can't
reasonably handle such connection failures without knowing the status code,
then the best solution is to avoid the server creating the ambiguity in the
first place. If it is important for the client that all the content is
consumed, then the server application should consume all the content, even if
there is an error. A filter can achieve that or perhaps a sendError wrapper.
We really don't want Jetty to have to do this consumeAll, because we then
cannot protect asynchronous apps with small thread pools from DOS attacks.
cheers
> Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate
> client connections.
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-8453
> URL: https://issues.apache.org/jira/browse/SOLR-8453
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> Assignee: Mark Miller
> Attachments: SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch,
> SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch,
> SOLR-8453_test.patch, SOLR-8453_test.patch, jetty9.2.pcapng, jetty9.3.pcapng
>
>
> The basic problem is that when we are streaming in updates via a client, an
> update can fail in a way that further updates in the request will not be
> processed, but not in a way that causes the client to stop and finish up the
> request before the server does something else with that connection.
> This seems to mean that even after the server stops processing the request,
> the concurrent update client is still in the process of sending the request.
> It seems previously, Jetty would not go after the connection very quickly
> after the server processing thread was stopped via exception, and the client
> (usually?) had time to clean up properly. But after the Jetty upgrade from
> 9.2 to 9.3, Jetty closes the connection on the server sooner than previous
> versions (?), and the client does not end up getting notified of the original
> exception at all and instead hits a connection reset exception. The result
> was random fails due to connection reset throughout our tests and one
> particular test failing consistently. Even before this update, it does not
> seem like we are acting in a safe or 'behaved' manner, but our version of
> Jetty was relaxed enough (or a bug was fixed?) for our tests to work out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
