https://issues.apache.org/jira/browse/SOLR-16909 > Collections LIST command should fetch ZK data, not cached state
I want to get further input from folks that changing the semantics is okay. If the change is applied, LIST will be much faster but it will return collections that have not yet been fully constructed or deleted. If a client/caller/user lists collections and then loops them to take some action on them, it needs to be tolerant of the collection not working; may seem to not exist. I argue callers should *already* behave in this way or it may be brittle to circumstances that are hard to reason about. On the other hand, maybe this would increase the frequency of errors to existing clients that didn't encounter this in testing? Shrug. I could imagine ways to solve this but it would add some complexity and it's not clear it's worthwhile. A related aside: the method ClusterStatus.getCollectionsMap is not scalable for clusters with 10K+ collections because it loops every collection to fetch the latest stake from ZK, putting a massive load on ZK. Our implementation of collection listing calls it, as does a number of places across Solr. Some could be changed with relative ease; some are more thorny. I'd love to rename this thing, putting "slow" in the name so that you think twice before calling it :-) ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
