[
https://issues.apache.org/jira/browse/SOLR-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133852#comment-18133852
]
David Smiley commented on SOLR-17153:
-------------------------------------
🤖 Retitled and redescribed to match what was actually merged and still in
place. The original client-side goal ("CloudSolrClient should not throw
'Collection not found' with an out-dated ClusterState") moved to SOLR-18606,
under umbrella SOLR-18154. Note that the 9.6 CHANGES entry for this issue
describes the client fix, which was reverted in 9.6.1.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
> HttpSolrCall: refresh ZK state before failing a request for an unknown
> collection
> ---------------------------------------------------------------------------------
>
> Key: SOLR-17153
> URL: https://issues.apache.org/jira/browse/SOLR-17153
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Priority: Major
> Labels: pull-request-available
> Fix For: 9.6
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> 🤖 When a Solr node receives a request for a collection missing from its local
> cluster state, it now refreshes aliases and force-updates that collection
> from ZooKeeper before failing. Previously only V2 API requests did this; now
> V1 {{/solr/<collection>/...}} requests do too. This helps when a node's ZK
> view lags, e.g. right after collection creation on a heavily loaded cluster.
> This issue originally also changed SolrJ's ZkClientClusterStateProvider to
> refresh on a miss. That part shipped only in 9.6.0 and was reverted in 9.6.1
> (SOLR-17275, performance regression with aliases). The original client-side
> goal continues in SOLR-18606, under umbrella 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]
