Alan Woodward resolved SOLR-9056.
    Resolution: Won't Fix

See SOLR-9659 for a different way of solving this.

> Add ZkConnectionListener interface
> ----------------------------------
>                 Key: SOLR-9056
>                 URL: https://issues.apache.org/jira/browse/SOLR-9056
>             Project: Solr
>          Issue Type: New Feature
>    Affects Versions: 6.0, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to