[
https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585493#comment-15585493
]
Keith Laban commented on SOLR-9056:
-----------------------------------
It would be great if we could use this for any generic zookeeper state changes.
There still a big pain point in trying to get notified for rest managed
resources changing, it requires building a zk watcher strategy from scratch.
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]