hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Hbase Assignments in trunk.
Date Thu, 06 Sep 2012 20:28:34 GMT
On Thu, Sep 6, 2012 at 3:16 AM, Jonathan Hsieh <jon@cloudera.com> wrote:
> On Wed, Sep 5, 2012 at 4:08 PM, Stack <stack@duboce.net> wrote:
>> On Wed, Sep 5, 2012 at 12:38 PM, Jonathan Hsieh <jon@cloudera.com> wrote:
>> We should post these invariants somewhere?  In dev section of refguide?
>> We should definitely put this in the javadoc.  Maybe we should have a
> dev-guide section of the ref-guide where some of these things are also
> captured?

I added an invariants section to the developer pages.  I used your
wording of the zk data axiom above.

(What other invariants do we have?)

>> On a code craft point of view, failure behavior is buried deeply and could
> be pulled out to the process methods of the handlers.  In many cases, it
> isn't easy to figure out why one behavior is chosen vs others.


> I'm also suggesting that we could avoid using ZK event callbacks like the
> OPENING and OPENED zk transition and instead have the master would manage
> those.  We'd have an opening RS would tickle some other znode to show
> progress.   At least then RegionState would be closer to accurate, and the
> HM would go through all state transitions.


I would look at any prospective design to see if I could see holes
where master and regionserver might diverge in terms of what they
think a particular region's state is at any one time (Up to this,
they've done it via the znode proxy that one or the other purportedly
owns outright at any time; there is even some facility for progressing
in the face of missed callbacks though for sure we are now into a gray


View raw message