Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
From: Apekshit Sharma <appy@cloudera.com>
Date: Mon, 23 Oct 2017 12:16:40 -0700
Message-ID: <CAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff+=Aj_epptO_XO812Abg@mail.gmail.com>
Subject: [DISCUSS] Fate of CoordinatedStateManager and hbase.coordinated.state.manager.class
 config
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary="001a113d10025120d7055c3bab20"
archived-at: Mon, 23 Oct 2017 19:17:15 -0000

--001a113d10025120d7055c3bab20
Content-Type: text/plain; charset="UTF-8"

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

--001a113d10025120d7055c3bab20--