lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Woodward (JIRA)" <>
Subject [jira] [Updated] (SOLR-9056) Add ZkConnectionListener interface
Date Mon, 02 May 2016 19:20:13 GMT


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
* 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
* 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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message