hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSS] Fate of CoordinatedStateManager and hbase.coordinated.state.manager.class config
Date Mon, 23 Oct 2017 20:15:21 GMT
Sounds good to me.


On Mon, Oct 23, 2017 at 1:00 PM, Apekshit Sharma <appy@cloudera.com> 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 <apurtell@apache.org>
> 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 <appy@cloudera.com>
> > 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
> >
>
>
>
> --
>
> -- Appy
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

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