[SOLR-9512] CloudSolrClient's cluster state cache can break direct updates to leaders

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 6.4
• Assignee: Noble Paul
• Reporter: Alan Woodward
• Created: 14/Sep/16 14:48
• Updated: 08/Jun/19 15:29
• Resolved: 29/Nov/16 15:28

Description

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.

Issue Links

• blocks: SOLR-9464 change CloudSolrClient[Builder].directUpdatesToLeadersOnly default (to true)
• is related to: SOLR-9784 Refactor CloudSolrClient to eliminate direct dependency on ZK
• is related to: SOLR-9090 solrj CloudSolrClient: add directUpdatesToLeadersOnly support
• relates to: SOLR-9927 revert HttpPartitionTest's avoidance of directUpdatesToLeadersOnly