[jira] [Commented] (SOLR-9056) Add ZkConnectionListener interface

["Scott Blum (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267392#comment-15267392 ] 

Scott Blum commented on SOLR-9056:
----------------------------------

Interested, but no bandwidth until we finish the other one. :)

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org