Details
Description
(copied from the design doc):
Redesign ZooKeeperListeners to abstract them from ZooKeeper API.
Current design:
The ZooKeeperListener interface is implemented by a number of classes and has 4 low-level API methods
- nodeCreated()
- nodeDeleted()
- nodeDataChanged()
- nodeChildrenChanged()
ZooKeeperWatcher maintains list of listeners and upon receiving ZK event calls all registered listeners and passes them affected znode’s path.
Proposed design:
- Create new interface ConsensusHandler that contains a single method, handle(Agreement agreement).
- Modify the classes currently implementing the ZooKeeperListener interface so they implement the new ConsensusHandler interface. In their handle(...) method they will typecast the agreement instance to specific type (like AssignmentAgreement), extract the information encoded in it, and do their work
- Create an interface called AgreementLearner which will maintain a list of all ConsensusHandlers as a map of znode prefixes to handler instance. The ZK implementation, ZkAgreementLearner, will be used to dispatch events to the appropriate namespaces in the ZooKeeperWatcher by parsing the znodes-level event, constructing Agreement objects of proper type and dispatching them to appropriate ConsensusHandlers.
- Modify ZooKeeperWatcher:
- remove the internal collection of ZooKeeperListeners
- move znode prefixes to ZkAgreementLearner class
- in the handle(...) method pass the event to ZkAgreementLearner for further dispatching and execution.
The following is a list of listeners to take care of (some are described in the items above already):
- ZKLeaderManager
- ZooKeeperNodeTracker
- TableHFileArchiveTracker
- ActiveMasterManager
- AssignmentManager
- SplitLogManager
- ZKProcedureUtil
- SplitLogWorker
- ZKPermissionWatcher
- ZKSecretWatcher
- ZKNamespaceManager
- DeletionListener
- DrainingServerTracker
- RecoveringRegionWatcher
- RegionServerTracker
- ReplicationPeer
- MasterAddressTracker
- MetaRegionTracker
- ClusterStatusTracker
- LoadBalancerTracker