[
https://issues.apache.org/jira/browse/SOLR-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-17153:
--------------------------------
Description:
_(Present status: reverted / not accomplished. New issues needed to continue)_
Today, CloudSolrClient will locally fail if it's asked to send a request to a
collection that it thinks does not exist due to its local ClusterState view
being out-of-date. We shouldn't fail! And most SolrCloud tests should then
remove their waitForState calls that follow collection creation! Other stale
state matters are out-of-scope.
Proposal: CloudSolrClient shouldn't try and be too smart. Always route a
request to Solr (any node); don't presume its state is up-to-date. Maybe,
after a response is received, it can check if its state has been updated and if
not then explicitly get a new state. Or not if that's too complicated.
was:
Today, CloudSolrClient will locally fail if it's asked to send a request to a
collection that it thinks does not exist due to its local ClusterState view
being out-of-date. We shouldn't fail! And most SolrCloud tests should then
remove their waitForState calls that follow collection creation! Other stale
state matters are out-of-scope.
Proposal: CloudSolrClient shouldn't try and be too smart. Always route a
request to Solr (any node); don't presume its state is up-to-date. Maybe,
after a response is received, it can check if its state has been updated and if
not then explicitly get a new state. Or not if that's too complicated.
> CloudSolrClient should not throw "Collection not found" with an out-dated
> ClusterState
> --------------------------------------------------------------------------------------
>
> 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
> Remaining Estimate: 0h
>
> _(Present status: reverted / not accomplished. New issues needed to
> continue)_
> Today, CloudSolrClient will locally fail if it's asked to send a request to a
> collection that it thinks does not exist due to its local ClusterState view
> being out-of-date. We shouldn't fail! And most SolrCloud tests should then
> remove their waitForState calls that follow collection creation! Other stale
> state matters are out-of-scope.
> Proposal: CloudSolrClient shouldn't try and be too smart. Always route a
> request to Solr (any node); don't presume its state is up-to-date. Maybe,
> after a response is received, it can check if its state has been updated and
> if not then explicitly get a new state. Or not if that's too complicated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
