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

Noble Paul commented on SOLR-9512:
----------------------------------

So in your solution here is what happens

# Instead of just passing one server , we pass all the nodes to 
LBHttpSolrClient (LBHSC). The shard leader should be the first in the list
# LBHSC knows that the leader is a dead node (or it will soon know that). So it 
would pick up the next server in the list and makes a request there
# The request would come back with an error (no leader)
# CSC returns the call with an error "no leader"

Is that right?

> CloudSolrClient's cluster state cache can break direct updates to leaders
> -------------------------------------------------------------------------
>
>                 Key: SOLR-9512
>                 URL: https://issues.apache.org/jira/browse/SOLR-9512
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Alan Woodward
>
> This is the root cause of SOLR-9305 and (at least some of) SOLR-9390.  The 
> process goes something like this:
> Documents are added to the cluster via a CloudSolrClient, with 
> directUpdatesToLeadersOnly set to true.  CSC caches its view of the 
> DocCollection.  The leader then goes down, and is reassigned.  Next time 
> documents are added, CSC checks its cache again, and gets the old view of the 
> DocCollection.  It then tries to send the update directly to the old, now 
> down, leader, and we get ConnectionRefused.



--
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

Reply via email to