This JIRA got me thinking of a more general topic. It may be controversial, but are there any thoughts around supporting alternatives to Zookeeper in the future? Would be cool if we could have a *functional* oriented internal APIs for Collections, live-nodes, config-sets, cluster-state etc, hiding the underlying technology. The first implementation would be a ZK, then we could further down the road provide other implementations for each, based upon e.g. Hazelcast or other suitable technologies.
I mean, we started down this abstraction path with ZkSolrResourceLoader as one of many implementations to resolve config/resources. But it kind of stopped there. Nowadays there are tons of “isZkAware” tests across our codebase, assuming there will ever only be two options: ZK or non-zk. You probably guessed already that I'd love a quicker way of launching a CloudCluster without setting up ZK, then people could move to ZK to get top notch robustness… That would perhaps be what we need to deprecate standalone mode forever, i.e. we would always run “cloud” even if powered by an in-memory config grid or similar. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 18. okt. 2016 kl. 14.26 skrev Alan Woodward (JIRA) <j...@apache.org>: > > > [ > https://issues.apache.org/jira/browse/SOLR-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Alan Woodward updated SOLR-9659: > -------------------------------- > Attachment: SOLR-9659.patch > > Patch, outlining the API, but not actually cutting over anything to use it > yet. > > There are two types of watch: > * DataWatch, called any time a znode is updated > * ChildWatch, called any time a znode's children are changed > > Both are registered with SolrZkClient, which maintains ZK watches and lists > of interested parties. When a znode is changed, or its children are changed, > the SolrZkClient will read the new data/new children, and then send this new > information to all registered watchers for that znode. ZK connection > exceptions are all handled internally. If a connection is dropped and > re-established, SolrZkClient will reset all ZK watches, read the latest data, > and notify all registered watchers. > >> Add zookeeper DataWatch API >> --------------------------- >> >> Key: SOLR-9659 >> URL: https://issues.apache.org/jira/browse/SOLR-9659 >> Project: Solr >> Issue Type: Improvement >> Security Level: Public(Default Security Level. Issues are Public) >> Reporter: Alan Woodward >> Assignee: Alan Woodward >> Attachments: SOLR-9659.patch >> >> >> We have several components which need to set up watches on ZooKeeper nodes >> for various aspects of cluster management. At the moment, all of these >> components do this themselves, leading to large amounts of duplicated code, >> and complicated logic for dealing with reconnections, etc, scattered across >> the codebase. We should replace this with a simple API controlled by >> SolrZkClient, which should make the code more robust, and testing >> considerably easier. > > > > -- > 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 >
