On Thu, Sep 6, 2012 at 3:16 AM, Jonathan Hsieh <j...@cloudera.com> wrote: > On Wed, Sep 5, 2012 at 4:08 PM, Stack <st...@duboce.net> wrote: > >> On Wed, Sep 5, 2012 at 12:38 PM, Jonathan Hsieh <j...@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
