Alan Woodward created SOLR-9056:
-----------------------------------
Summary: Add ZkConnectionListener interface
Key: SOLR-9056
URL: https://issues.apache.org/jira/browse/SOLR-9056
Project: Solr
Issue Type: New Feature
Affects Versions: master, 6.1
Reporter: Alan Woodward
Assignee: Alan Woodward
Zk connection management is currently split among a few classes in
not-very-helpful ways. There's SolrZkClient, which manages general interaction
with zookeeper; ZkClientConnectionStrategy, which is a sort-of connection
factory, but one that's heavily intertwined with SolrZkClient; and
ConnectionManager, which doesn't actually manage connections at all, but
instead is a ZK watcher that calls back into SolrZkClient and
ZkClientConnectionStrategy.
We also have a number of classes that need to be notified about ZK session
changes - ZkStateReader sets up a bunch of watches for cluster state updates,
Overseer and ZkController use ephemeral nodes for elections and service
registry, CoreContainer needs to register cores and deal with recoveries, and
so on. At the moment, these are mostly handled via ZkController, which
therefore needs to know how about the internals of all these different classes.
There are a few other places where this co-ordination is duplicated, though,
for example in CloudSolrClient. And, as is always the case with duplicated
code, things are slightly different in each location.
I'd like to try and rationalize this, by refactoring the connection management
and adding a ZkConnectionListener interface. Any class that needs to be
notified when a zk session has expired or a new session has been established
can register itself with the SolrZkClient. And we can remove a whole bunch of
abstraction leakage out of ZkController, and back into the classes that
actually need to deal with session changes. Plus, it makes things a lot easier
to test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
