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/03/09 00:12:38 UTC
[jira] [Comment Edited] (SOLR-7203) NoHttpResponseException
handling in HttpSolrClient is wrong
[ https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352332#comment-14352332 ]
Mark Miller edited comment on SOLR-7203 at 3/8/15 11:12 PM:
------------------------------------------------------------
Since we seem to have gotten past that, moving on:
In some cases, if we can properly detect certain things, we do want an auto retry. On read only operations, this makes complete sense. I also think, if its an update or a delete and optimistic locking is being used, that may be okay too. The part with holes is when a new doc comes in, some other client doing periodic updates to docs that match a certain criteria updates it, and then retry number 3 hits and undoes the update that was acked against a doc that was already part of the system according to client 2. If you do that type of auto retry on internode communication, it may also vary replica to replica which update survives - and once a replica gets out of sync, unless you have a very simple add only system, fixing the issue without data loss is almost impossible in all cases.
Finally, overall, we probably want the retry behavior centered in one spot - the retryhandler used by the HttpClient. Having retry logic there and at a higher level gets confusing.
was (Author: markrmiller@gmail.com):
Since we seem to have gotten past that, moving on:
In some cases, if we can properly detect certain things, we do want an auto retry. On read only operations, this makes complete sense. I also think, if its an update or a delete and optimistic locking is being used, that may be okay too. The part with holes is when a new doc comes in, some other client doing periodic updates to docs that match a certain criteria updates it, and then retry number 3 hits and undoes the update that was acked against a doc that was already part of the system according to client 2. If you do that type of auto retry on internode communication, it may also very replica to replica which update survives - and once a replica gets out of sync, unless you have a very simple add only system, fixing the issue without data loss is almost impossible in all cases.
Finally, overall, we probably want the retry behavior centered in one spot - the retryhandler used by the HttpClient. Having retry logic there and at a higher level gets confusing.
> NoHttpResponseException handling in HttpSolrClient is wrong
> -----------------------------------------------------------
>
> Key: SOLR-7203
> URL: https://issues.apache.org/jira/browse/SOLR-7203
> Project: Solr
> Issue Type: Bug
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Attachments: SOLR-7203.patch, SOLR-7203.patch
>
>
> We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. However, this logic appears to be in the wrong place - it's in the createMethod function, which doesn't actually execute any http requests at all. It ought to be in executeMethod.
> Fixing this might help sort out the persistent Jenkins failures as well.
--
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