hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12476) HydraBase Consensus Protocol
Date Thu, 27 Nov 2014 13:13:14 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227636#comment-14227636
] 

stack commented on HBASE-12476:
-------------------------------

Here are some notes on the 0002 patch itself.  Mostly questions. No hurry w/ response.

Purge versions from sub-poms if the dependency is common with other modules. Inherit from
parent where you can. I found this in the consensus pom:

          <version>2.15</version>

and
          <version>4.1</version>

... for what I believe are common dependencies (Its fine to have dependencies in modules with
versions if the dependency only used by the submodule)

In the consensus module, there is an hbase-default.xml also? How does it relate to the one
over in hbase-common?

You can purge hadoop-1 references (unless that is how you refer to your hdfs.)  We don't support
it in hbase 1.0.

Others have already remarked on undoing the local copies of HColumnDescriptor, etc. You had
them in here so this module could 'work' without dependency? (Kill HServerAddress!)  Do we
need to move stuff around in hbase so you can have minimal dependencies?  All the classes
you have copied local here, should we move them back up and into hbase-common module if not
there already?

Run the rat tool on your feature branch. Some of these files are still missing licenses.

Nice. You have already ported over ConfigurationObserver.  Good.

We'll have to redo FetchTask, etc., as protobuf? (the swifty annotations look very nice)

In FetchTask I see in the run that it has this:

	    // TODO in part 2: fetch log files from the peer!

Does that mean this facility of raft -- catchup I presume -- is yet to be implemented or is
it rather that this class gets subclassed later?

If the former, is there more to do to have full implementation?

Each regionserver stands up an instance of a QuorumClient per region?

A quorum name is different from region name?

We'd have to move all of the quorum communication up on to hbase rpc and pb?  What you lot
think?  Keep swift?

The FSM stuff could do w/ a bit of package doc on how it works.  That said, it is easy to
read.  (Maybe we could use these primitives elsewhere in hbase)

Region splits handled?

We'd have to figure how to do the RMap stuff in master? And bootstrapping the cluster?

A regionserver would have to do consensuservice?

WHen you say 'favored_nodes' in the rmap, does that imply we need 'favored nodes' working
out in apache hbase or is this just how you describe quorum members for a region?

Is the read-side, reading from the quorum, a patch as big as this one (smile)?

Nice one.

















> HydraBase Consensus Protocol
> ----------------------------
>
>                 Key: HBASE-12476
>                 URL: https://issues.apache.org/jira/browse/HBASE-12476
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Consensus, wal
>            Reporter: Gaurav Menghani
>            Assignee: Gaurav Menghani
>         Attachments: 0001-HydraBase-consensus-protocol.patch, 0002-HydraBase-consensus-protocol.patch
>
>
> This is the first patch for the HydraBase consensus protocol implemented according to
the Raft consensus protocol (https://ramcloud.stanford.edu/raft.pdf), as advertised in (HBASE-12259)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message