Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com
 designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CAAha9a0C=x+zY2Lw0AeJR+beYsaCCdMK6P-xEOn01GcGWcTw0A@mail.gmail.com>
References: 
 <CAAha9a2W1Zer-115deHfoi+RiACSu_MokGeipGSZEswPkRiVpw@mail.gmail.com>
	<CADcMMgG6kLOLVEEijWGz1gztU4n1bCbVMcHp7nt0G3VVS-woJw@mail.gmail.com>
	<CAAha9a0C=x+zY2Lw0AeJR+beYsaCCdMK6P-xEOn01GcGWcTw0A@mail.gmail.com>
Date: Thu, 6 Sep 2012 13:28:34 -0700
Message-ID: 
 <CADcMMgEavmW1gVF3VaJ=kUUGa+yUXTYwqHd60rH1PNHSkqQ6FQ@mail.gmail.com>
Subject: Re: Hbase Assignments in trunk.
From: Stack <stack@duboce.net>
To: dev@hbase.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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.
>

Nod.

> 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.
>

Perhaps.

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
area).

St.Ack