[jira] [Updated] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.
[ https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-8453: -- Attachment: SOLR-8453.patch I think this patch is okay. I change consomeInput to not throw out an Exception , instead we just log it, and I added a bit of doc that links to this JIRA. > 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.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
[jira] [Updated] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.
[ https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-8453: -- Attachment: SOLR-8453.patch Okay here is a patch that has the filter read out the inputstream on errors. > 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.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
[jira] [Updated] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.
[ https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-8453: -- Attachment: jetty9.3.pcapng jetty9.2.pcapng > 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
[jira] [Updated] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.
[ https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-8453: -- Summary: Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections. (was: Local exceptions in DistributedUpdateProcessor should not cut off an ongoing request.) > 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 > > > 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
