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

Mike Drob commented on SOLR-9555:
---------------------------------

bq. I think we should take this opportunity to stop trying to do LIR per update
My patch kind of does this.

Before, we would locally mark a follower as in LIR after a failed update. Then 
when the LIR thread successfully sent a recovery request, we would unmark it, 
after which we start sending more updates (to buffer) and if those fail more 
requests. This could lead to a lot of recovery requests stacking up, hence the 
need to discard them at the follower.

With my patch, we still locally mark a replica as in LIR. However, we won't 
unmark it until we see that it has ack'd the LIR update in ZK and updated 
itself to 'recovering'. I don't know how fast this process can be, maybe it can 
still be 1000s per second. I imagine that going through ZK and having to wait 
long enough to actually start a recovery necessarily makes it slower.

If it's still bad, we can add a configurable 100ms sleep to the start of any 
recovery. In actual use, it shouldn't affect things too much since the rest of 
the recovery will be much longer, but it would be enough to throttle things.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-9555
>                 URL: https://issues.apache.org/jira/browse/SOLR-9555
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Alan Woodward
>         Attachments: SOLR-9555.patch, SOLR-9555-WIP-2.patch, 
> SOLR-9555-WIP-3.patch, SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to