[ https://issues.apache.org/jira/browse/SOLR-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583374#comment-15583374 ]
Christine Poerschke commented on SOLR-9512: ------------------------------------------- Thanks Shalin and Noble for analysing and summarising this. The proposed cases 1-5 solution sounds good to me (though i have not actually looked at the code concerned to see what the implementation of that solution might look like). Case 6: do i understand it right that we would keep failing the indexing requests but 'only' until eventually the client manages to reconnect to zk? I agree that asking a random solr instance for its latest cluster state could be problematic. > 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 > Attachments: SOLR-9512.patch > > > 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