[
https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088327#comment-15088327
]
Greg Wilkins commented on SOLR-8453:
------------------------------------
Copying this comment over from the jetty-users discussion (and expanding
somewhat)
This is indeed a change in behaviour in jetty 9.3, but not one that should
affect any application.
The problem with consumeAll previously is that it was an unlimited commitment -
a client could send chunks forever and consume a thread forever. The only
reason we need to consume all is to maintain a persistent connection. But a
server is under no obligation to maintain a persistent connection (even if the
application consumes all the request data). So if jetty doesn't consumeAll, we
can close that connection and the client needs to start a new one.
So the approach that 9.3 takes is that if the application has not read all it's
content (which is normally an error condition of the application), then jetty
will make a best effort attempt to read the content, but only if it can do so
without blocking. If it has to block - it gives up and the connection is
closed. The decision is that it is better to throw away the connection rather
than commit to blocking for an unknown period of time. This is more important
now as apps are using the async APIs and are configured with minimal
threadpools - thus we need to avoid places where the container can block and
consume the thread pool (and thus be vulnerable to DOS attacks).
So your client needs to be more robust in this circumstance and/or your
application should make a better attempt to consume all the data.
Even if we reinstated the behaviour in jetty - it would really just be
happenstance that your client works and intermediaries/proxies could change the
behaviour.
> 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
