hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apekshit Sharma <a...@cloudera.com>
Subject [DISCUSS] Fate of CoordinatedStateManager and hbase.coordinated.state.manager.class config
Date Mon, 23 Oct 2017 19:16:40 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message