You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2015/12/22 16:45:46 UTC
[jira] [Comment Edited] (SOLR-8453) Local exceptions in
DistributedUpdateProcessor should not cut off an ongoing request.
[ https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068279#comment-15068279 ]
Mark Miller edited comment on SOLR-8453 at 12/22/15 3:45 PM:
-------------------------------------------------------------
I have not seen any failures due to that change and have been running it for a lot of days. I don't know that it's very important for this issue though - I'll probably pare a couple of those things out or into their own issues. I think most tests now are actually using that wait till cores are loaded option anyway? Logically, this does make more sense to me though.
I'm still fighting with some DIH tests a little. Their test classes really want the 'old processor throws out an exception' behavior - and while I can easily simulate that, it seems that also leaves those tests with the random connection reset issue. Old behavior, old problem I guess. Will probably have to try and tweak those tests a bit more.
was (Author: markrmiller@gmail.com):
I have not seen any failures due to that change and have been running it for a lot of days. I don't know that it's very important for this issue though - I'll probably pare a couple of those things out or into their own issues. I think most tests now are actually using that wait till cores are loaded option anyway? Logically, this does make more sense to me though.
I'm still fighting with some DIH tests a little. There test classes really want the old processor throws out exception behavior - and while I can easily simulate that, it seems that also leaves those tests with the random connection reset issue.
> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org