Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 30ED1200D28 for ; Mon, 23 Oct 2017 22:16:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2F7371609E0; Mon, 23 Oct 2017 20:16:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 74A5C1609DF for ; Mon, 23 Oct 2017 22:16:07 +0200 (CEST) Received: (qmail 80074 invoked by uid 500); 23 Oct 2017 20:16:06 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 80063 invoked by uid 99); 23 Oct 2017 20:16:06 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Oct 2017 20:16:06 +0000 Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 3F7C41A0040 for ; Mon, 23 Oct 2017 20:16:04 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id h200so32999468oib.4 for ; Mon, 23 Oct 2017 13:16:03 -0700 (PDT) X-Gm-Message-State: AMCzsaWG8bJd4EXldZrI5IFLTq7Gwc7YB+/qZUgx+cWQxgsr02fAG65E q0452Kwv0zB1AgcnrNtrZUjnplaquYBcWQ87oqU= X-Google-Smtp-Source: ABhQp+QHMwq3OL6GMKtZSyC1DtL986lWe23oiU8wrVsUuybhXRB7mRG8NoGMpCSMEIWfEBaj5kI/7+xo4NMLbPNyntI= X-Received: by 10.157.45.80 with SMTP id v74mr8029206ota.38.1508789762063; Mon, 23 Oct 2017 13:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.242 with HTTP; Mon, 23 Oct 2017 13:15:21 -0700 (PDT) In-Reply-To: References: From: Andrew Purtell Date: Mon, 23 Oct 2017 13:15:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [DISCUSS] Fate of CoordinatedStateManager and hbase.coordinated.state.manager.class config To: "dev@hbase.apache.org" Content-Type: multipart/alternative; boundary="001a113adc3ecf0303055c3c7da3" archived-at: Mon, 23 Oct 2017 20:16:08 -0000 --001a113adc3ecf0303055c3c7da3 Content-Type: text/plain; charset="UTF-8" Sounds good to me. On Mon, Oct 23, 2017 at 1:00 PM, Apekshit Sharma wrote: > Thanks Andrew! > > How does the following cleanup sounds? > > - Remove the configuration hbase.coordinated.state.manager.class > - Keep following interface since they nicely separate ZK based > implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination, > ProcedureCoordinatorRpcs, ProcedureMemberRpcs > - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single > CSM interface. > > @InterfaceAudience.Private > public interface CoordinatedStateManager { > void initialize(Server server) > SplitLogWorkerCoordination getSplitLogWorkerCoordination(); > SplitLogManagerCoordination getSplitLogManagerCoordination(); > ProcedureCoordinatorRpcs getProcedureCoordinatorRpcs(String procType, > String coordNode) throws IOException; > ProcedureMemberRpcs getProcedureMemberRpcs(String procType) throws > KeeperException; > } > > On Mon, Oct 23, 2017 at 12:37 PM, Andrew Purtell > wrote: > > > 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 > > wrote: > > > > > Hi everyone, > > > > > > Am coming from limited knowledge here, so pardon me if it seems > > outrageous. > > > I guess this effort (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 > > > 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 > > > > > > -- > > -- Appy > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk --001a113adc3ecf0303055c3c7da3--