[
https://issues.apache.org/jira/browse/SOLR-16909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17905542#comment-17905542
]
Matthew Biscocho commented on SOLR-16909:
-----------------------------------------
[~dsmiley] [~gerlowskija] Read the dev-list discussion and was curious to bring
this back up. From my understanding, the concern of fetching the child znodes
from ZK is that the collections returned may not actually be ready for any
action?
This makes sense as it can be confusing but this LIST command isn't actually a
healthcheck, is that correct? Shouldn't the users be using the `CLUSTERSTATUS`
api with a `collection` parameter to verify the health of the collection before
doing an action or like was said on the mailing list, error handle correctly?
If the performance gain went from 75ms to 1.7ms (4000%) increase in
performance, this seems like a big improvement for a somewhat trivial change.
Also if the command returns the collection, it's not technically incorrect. The
collection exists in ZK and returned the info at that point in time.
Maybe the ref-guide can just mention that the LIST command should not be used
as a healthcheck but gives you list of collections that exists but isn't
necessarily healthy.
> Collections LIST command should fetch ZK data, not cached state
> ---------------------------------------------------------------
>
> Key: SOLR-16909
> URL: https://issues.apache.org/jira/browse/SOLR-16909
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
>
> The LIST command to the Collections API presently returns all collections
> from the cached ClusterState. The proposal here is to fetch the child nodes
> in ZooKeeper instead. While the distinction is minor, the intent is to
> improve robustness / comprehensiveness. It may mean a collection is listed
> that is being created or being deleted that otherwise might not have been
> returned. The scenario driving this is to facilitate cleanup daemons that
> identify potentially left-over data from a collection creation or deletion
> that maybe failed (partial create or delete).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
