[
https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-8453:
-------------------------------
Attachment: SOLR-8453_test.patch
Here's a test with normal solrj clients that reproduces HTTP level exceptions.
It uses multiple threads and large request sizes.
Example exception summary (from 10 clients):
{code}
3567 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->SocketException(Connection reset)
3569 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3569 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3570 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3571 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3571 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3571 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3572 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3572 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3572 ERROR (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.c.s.TestSolrJErrorHandling CHAIN:
->SolrServerException->ClientProtocolException->NonRepeatableRequestException->SocketException(Broken
pipe)
3573 INFO (TEST-TestSolrJErrorHandling.testWithBinary-seed#[5C3578C3D02417A3])
[ ] o.a.s.SolrTestCaseJ4 ###Ending testWithBinary
{code}
> Local exceptions in DistributedUpdateProcessor should not cut off an ongoing
> request.
> -------------------------------------------------------------------------------------
>
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
