[
https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward updated SOLR-9056:
--------------------------------
Attachment: SOLR-9056.patch
Patch. It's a bit of a biggie, so I can open a pull request if anyone's
interested in commenting that way.
* removes ConnectionManager and ZkClientConnectionStrategy, and replaces them
with a ZkConnectionFactory. This just has a createSolrZookeeper(Watcher
watcher) method.
* SolrZkClient now exposes a registerConnectionListener() method
* When a listener is registered, if the client is already connected, it will
call the listener's onConnect() method.
* SolrZkClient has its own internal zk Watcher which it passes to
ZkConnectionFactory.createSolrZookeeper(). This means that SZK can now manage
its own connections.
* When a session expires, SolrZkClient calls the onSessionExpiry() method of
all its registered listeners
* When a session has been re-established, SolrZkClient calls the onConnect()
method of all its registered listeners
* Network hiccups that don't cause session expiry are handled internally, and
don't call out to listeners at all.
* ZkController now implements ZkConnectionListener, and registers itself with
its internal client
* ZkStateReader now implements ZkConnectionListener
There are a whole bunch of other things to do in follow-up (Overseer and
CoreContainer should be ZkConnectionListeners, migrate the ZkController
listeners, etc), but this patch is big enough as it is.
> 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
> Attachments: SOLR-9056.patch
>
>
> 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]
