[jira] [Commented] (SOLR-9056) Add ZkConnectionListener interface
[ https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585525#comment-15585525 ] Alan Woodward commented on SOLR-9056: - [~k317h] see SOLR-9659! > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9056) Add ZkConnectionListener interface
[ https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9056) Add ZkConnectionListener interface
[ https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267398#comment-15267398 ] Alan Woodward commented on SOLR-9056: - Right, one major internal ZK refactoring at a time... > 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9056) Add ZkConnectionListener interface
[ https://issues.apache.org/jira/browse/SOLR-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
