You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Konstantin Boudnik (JIRA)" <ji...@apache.org> on 2014/05/02 03:32:16 UTC

[jira] [Updated] (HBASE-11073) Hide ZooKeeperWatcher and dependent ZK Listeners inside of a consensus impl

     [ https://issues.apache.org/jira/browse/HBASE-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konstantin Boudnik updated HBASE-11073:
---------------------------------------

    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


  was:
(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



> Hide ZooKeeperWatcher and dependent ZK Listeners inside of a consensus impl
> ---------------------------------------------------------------------------
>
>                 Key: HBASE-11073
>                 URL: https://issues.apache.org/jira/browse/HBASE-11073
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Consensus, Zookeeper
>    Affects Versions: 0.99.0
>            Reporter: Mikhail Antonov
>            Assignee: Mikhail Antonov
>
> (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



--
This message was sent by Atlassian JIRA
(v6.2#6252)