[
https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352332#comment-14352332
]
Mark Miller commented on SOLR-7203:
-----------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
