Christine Poerschke commented on SOLR-9512:

Hi [~romseygeek] and [~noble.paul] - am only now joining this ticket late here 
since i have been on vacation.

The SOLR-9090 {{directUpdatesToLeadersOnly}} motivation/intention was for the 
flag to be not a hint but a directive and for updates to 'fail fast' if there 
is (temporarily or otherwise) no shard leader. Fail fast (and let the caller of 
the {{CloudSolrClient}} handle alarming and retries as it sees fit) as opposed 
to sending or retry-sending to a non-leader which would then forward to the 
leader (and potentially still fail eventually, eventually/not-fast-slowly).

[~Marvin Justice] and I worked together on SOLR-9090 - Marvin, any thoughts on 
this ticket here?

> 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

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

Reply via email to