[ 
https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068201#comment-15068201
 ] 

Shalin Shekhar Mangar commented on SOLR-8453:
---------------------------------------------

This is great, thanks for debugging this.

If you move the following to the life cycle started method then you should also 
increase the timeout in the start() method because currently it gives up 
waiting for solr in 500ms.
{code}
synchronized (JettySolrRunner.this) {
          waitOnSolr = true;
          JettySolrRunner.this.notify();
        }
{code}

Did you see any test failures after this change? When I tried moving waitOnSolr 
to life cycle started, it failed many tests. However, I tried only once so it 
may have been the locale problems we've seen in other places. I'll run the 
tests in a loop with this patch to see if I can reproduce the failures.

> 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
>
>
> 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 streaming more 
> updates.
> This seems to mean that even after the server stops processing the request, 
> the concurrent update client is sending out some further updates. It seems 
> previously this burst was sent on the connection and ignored? But after the 
> Jetty upgrade from 9.2 to 9.3, Jetty closes the connection on the server when 
> we throw certain document level exceptions, and the client does not end up 
> getting notified of the original exception at all and instead hits a 
> connection reset exception. Even before this update, it does not seem like we 
> are acting in a safe or 'behaved' manner.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to