[ https://issues.apache.org/jira/browse/SOLR-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15498629#comment-15498629 ]
Alan Woodward commented on SOLR-9512: ------------------------------------- It's kicking the can to a live server, though, which will be able to tell us either a) yes, everything's fine now, you just need to invalidate your cache, or b) there's no leader for this shard, so fail the update. Either way, we get useful information, whereas at the moment we're trying to find out what's happening from a dead server. > 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