[
https://issues.apache.org/jira/browse/SOLR-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14141269#comment-14141269
]
Alan Woodward commented on SOLR-6511:
-------------------------------------
I think the safest response is to return the error to the client. Updates are
idempotent, right? An ADD will just overwrite the previous ADD, DELETE doesn't
necessarily have to delete anything to be successful, etc. So if the client
gets a 503 back again it can just resend.
The only tricky bit might be what happens if a replica finds itself ahead of
its leader, as would be the case here. Does it automatically try and send
updates on, or does it roll back?
> Fencepost error in LeaderInitiatedRecoveryThread
> ------------------------------------------------
>
> Key: SOLR-6511
> URL: https://issues.apache.org/jira/browse/SOLR-6511
> Project: Solr
> Issue Type: Bug
> Reporter: Alan Woodward
> Assignee: Timothy Potter
> Attachments: SOLR-6511.patch
>
>
> At line 106:
> {code}
> while (continueTrying && ++tries < maxTries) {
> {code}
> should be
> {code}
> while (continueTrying && ++tries <= maxTries) {
> {code}
> This is only a problem when called from DistributedUpdateProcessor, as it can
> have maxTries set to 1, which means the loop is never actually run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
