This work was done by a small development group at WANDisco. The intent was to allow substitution of a proprietary consensus and state replication service for ZooKeeper. There hasn't been progress on this for a long time. I think it is safe for us to clean it up. No need necessarily to abandon the idea of abstraction between our coordination needs and the implementation.
On Mon, Oct 23, 2017 at 12:16 PM, Apekshit Sharma <[email protected]> wrote: > Hi everyone, > > Am coming from limited knowledge here, so pardon me if it seems outrageous. > I guess this effort (HBASE-10909 > <https://issues.apache.org/jira/browse/HBASE-10909>) was to separate out > state into an interface which was then made pluggable via the config > hbase.coordinated.state.manager.class. > > - Is this effort complete? Can someone use it to completely switch out ZK > based state with something else? I see all tasks in HBASE-10909 > <https://issues.apache.org/jira/browse/HBASE-10909> are complete, but it's > named 'phase1' and i don't see a phase2. > > - Is anyone aware of any use cases where it's actually being used to > replace zk? > > ** If yes, I think that at the very least, we should clean it up (more on > it further down) and made these relevant interfaced IA.Public. > > ** If not, can we get rid of the (incomplete??) 'feature' and do more > rigorous cleanup? I'll sign up for it. > --------- > > Cleanup: > Our internal class hierarchy is: > CoordinatedStateManager -> BaseCoordinatedStateManager -> > ZkCoordinatedStateManager. > > - We carry around CSM objects but cast them to BCSM in so many places! If > anyone implements CSM and plugs it in, it won't work. Better to just unify > them and make it easier to understand. > > > -- Appy > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
