lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: CloudSolrClient getDocCollection
Date Sat, 09 Feb 2019 19:40:22 GMT
Jason's comments are exactly why there _is_ a state.json per
collection rather than the single clusterstate.json in the original

yes, please do open a JIRA for the condition you observed,
especially if you can point to the suspect code. There have
been intermittent issues with collection creation in the test

About the watchers.

bq. Yes, you would need one watch per state.json and
thus one watch per collection. That should however not really be a
problem with ZK.

Consider an installation I have witnessed with 450K replicas scattered
over 100s of collections and 100s of JVMs. Each JVM may have one
or more CloudSolrClients. Are you _sure_ ZK can handle that kind
of watch load? The current architecture allows there to be many fewer
watches set, partially to deal with this scale. And even at this scale,
an incoming request to a node that does _not_ host _any_ replica of
the target collection needs to be able to forward the request, but doesn't
need to know much else about the target collections.


On Fri, Feb 8, 2019 at 5:23 PM Hendrik Haddorp <> wrote:
> Hi Jason,
> thanks for your answer. Yes, you would need one watch per state.json and
> thus one watch per collection. That should however not really be a
> problem with ZK. I would assume that the Solr server instances need to
> monitor those nodes to be up to date on the cluster state. Using
> you can even add a watch for that using the SolrJ API. At least for the
> currently watched collections the client should thus actually already
> have the correct information available. The access to that would likely
> be a bit ugly though.
> The CloudSolrClient also allows to set a watch on /collections using
> This is actually another thing I just ran into. As the code has a watch
> on /collections the listener gets informed about new collections as soon
> as the "directory" for the collection is being created. If the listener
> does then straight away try to access the collection info via
> zkStateReader.getClusterState() the DocCollection can be returned as
> null as the DocCollection is build on the information stored in the
> state.json file, which might not exist yet. I'm trying to monitor the
> Solr cluster state and thus ran into this. Not sure if I should open a
> Jira for that.
> regards,
> Hendrik
> On 08.02.2019 23:20, Jason Gerlowski wrote:
> > Hi Henrik,
> >
> > I'll try to answer, and let others correct me if I stray.  I wasn't
> > around when CloudSolrClient was written, so take this with a grain of
> > salt:
> >
> > "Why does the client need that timeout?....Wouldn't it make sense to
> > use a watch?"
> >
> > You could probably write a CloudSolrClient that uses watch(es) to keep
> > track of changing collection state.  But I suspect you'd need a
> > watch-per-collection, instead of just a single watch.
> >
> > Modern versions of Solr store the state for each collection in
> > individual "state.json" ZK nodes
> > ("/solr/collections/<collection_name>/state.json").  To catch changes
> > to all of these collections, you'd need to watch each of those nodes.
> > Which wouldn't scale well for users who want lots of collections.  I
> > suspect this was one of the concerns that nudged the author(s) to use
> > a cache-based approach.
> >
> > (Even when all collection state was stored in a single ZK node, a
> > watch-based CloudSolrClient would likely have scaling issues for the
> > many-collection use case.  The client would need to recalculate its
> > state information for _all_ collections any time that _any_ of the
> > collections changed, since it has no way to tell which collection was
> > changed.)
> >
> > Best,
> >
> > Jason
> >
> > On Thu, Feb 7, 2019 at 11:44 AM Hendrik Haddorp <>
> >> Hi,
> >>
> >> when I perform a query using the CloudSolrClient the code first
> >> retrieves the DocCollection to determine to which instance the query
> >> should be send [1]. getDocCollection [2] does a lookup in a cache, which
> >> has a 60s expiration time [3]. When a DocCollection has to be reloaded
> >> this is guarded by a lock [4]. Per default there are 3 locks, which can
> >> cause some congestion. The main question though is why does the client
> >> need that timeout? According to this [5] comment the code does not use a
> >> watch. Wouldn't it make sense to use a watch? I thought the big
> >> advantage of the CloudSolrClient is that is knows were to send requests
> >> to, so that no extra hop needs to be done on the server side. Having to
> >> query ZooKeeper though for the current state does however take some of
> >> that advantage.
> >>
> >> regards,
> >> Hendrik
> >>
> >> [1]
> >>
> >> [2]
> >>
> >> [3]
> >>
> >> [4]
> >>
> >> [5]
> >>

View raw message