[
https://issues.apache.org/jira/browse/SOLR-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250898#comment-15250898
]
Scott Blum commented on SOLR-9014:
----------------------------------
Hard to get the right context in mind in all these cases, eh?
1. If the overseer had set a watch on the collection it cared about, it would
be more efficient to wait and loop. Maybe we could fix this via SOLR-8323?
Overseer could set a temporary watch on things it cared about.
One thing puzzles me in what you said tho; if the collection is lazy but
existent, I think forceUpdateCollection() is basically exactly as efficient as
just polling the lazy collection. So going back to forceUpdateCollection()
won't make it any better. But in cases where the collection is watching,
looping is far more efficient.
2) Agreed, maybe we should expose getCollectionStates() or getCollectionNames().
> Audit all usages of ClusterState methods which may make calls to ZK via the
> lazy collection reference
> -----------------------------------------------------------------------------------------------------
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.1
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which
> internally call getCollectionOrNull that ends up making a call to ZK via the
> lazy collection reference. Many classes use these methods even though a
> DocCollection object is available. In such cases, multiple redundant calls to
> ZooKeeper can happen if the collection is not watched locally. This is
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to
> appropriate DocCollection methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
