David Smiley created SOLR-18606:
-----------------------------------
Summary: 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
🤖 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]
