[
https://issues.apache.org/jira/browse/SOLR-18606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140817#comment-18140817
]
Nick Shanin edited comment on SOLR-18606 at 11/8/26, 6:39 PM:
--------------------------------------------------------------
I want to work on this. Please approve the proposed scope:
Routes requests for locally unknown collections through live nodes, preserving
the requested collection or alias. For strict direct-leader updates, I suggest
failing when the client cannot determine the leaders, rather than routing
through an arbitrary node. Does that tradeoff sound right?
was (Author: JIRAUSER314749):
I want to work on this. Please approve the proposed scope:
Routes requests for locally unknown collections through live nodes, preserving
the requested collection or alias. Strict direct-leader mode conservatively
rejects updates when collection state is unavailable.
> CloudSolrClient should not fail locally for a just-created collection
> ---------------------------------------------------------------------
>
> Key: SOLR-18606
> URL: https://issues.apache.org/jira/browse/SOLR-18606
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Priority: Major
>
> 🤖 Continuation of the original goal of SOLR-17153, whose client-side change
> was reverted by SOLR-17275.
> CloudSolrClient may fail locally ("Collection not found") when asked to send
> a request to a collection it thinks doesn't exist because its local
> ClusterState is out of date, e.g. right after the collection was created. It
> shouldn't fail. Other stale-state matters are out of scope.
> Proposal: CloudSolrClient shouldn't try to be too smart. If the collection is
> unknown locally, route the request to any live node instead of failing. The
> server side already refreshes from ZK on a miss (SOLR-17153). Optionally,
> after a response, refresh the local state.
> Notes:
> * The obvious fix, forcing a ZK refresh on every miss in
> ZkClientClusterStateProvider, caused a severe performance regression with
> aliases (SOLR-17275). Avoid repeating it.
> * HttpClusterStateProvider may already behave correctly, since it fetches on
> a miss. Verify, especially since SOLR-17947 changed caching. The ZK-based
> provider learns about new collections asynchronously and is the likely
> culprit. SOLR-17605 (HTTP-only CloudSolrClient) might make this moot.
> Required for SOLR-18154.
> 🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
