Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Hbase Assignments in trunk.

Copy link to this message
Hbase Assignments in trunk.
I generally think in pictures, so I've mapped out the single Assignment
control flow as found in trunk yesterday in terms of threads and network
communications (each of which can possibly fail).  It is a process that has
18 or so network communications, 3 processes, and about 8 threads
coordinating (excluding meta writes)

I wanted to put this out because we've had some discussions about
simplifying it or making it more accessible so we can comfortably access
patches and possibly use it as a rough design doc or a counter to new
potential strawman designs.  For me at least it would be useful when
reviewing patches in this area.

We've also talked about defining design and code invariants -- here's the
one that I've gotten so far:  (We can pull up more from discussion)

* ZK state should transient (treat it like memory). If deleted, hbase
should be able to recover and essentially be in the same state (a few
exceptions -- enabled/disable state)

A few questions I have from this exercise:

1) Why do we have ZK asynchronously update the HM?  (why not do it
2) Why do we have the RS update ZK as it opens -- why not have the HM
manage all ZK comms and not have the RS talk directly to ZK in this
process?  Then ZK is just for failover and less so for coordination.
3) Clients who issue assign calls are partially asynchronous and partially
synchronous.  Why not go all the way?
4) Why are there multiple error conventions -- abort, FAILED_OPEN, throwing
exception, (and cases where we "return" silently without notification)?
5) How do we handle timeout situations -- IMO it makes sense to have a
rollback or fail forward policy for different places on the timeline.
6) Can we use cancellation instead of checking for
enabling/disabled/disabling/shutdown/stopping all over the place? (let's
say these cluster ops would cancel the assign and then win by blocking
7) In memory state has different but similarly named states in the HM, ZK,
and in the RS's.  And there are the transition events could be missed.
8) Is having multiple processes "responsible for acting" necessary?  (why
not have the HM open and then update meta)?

Thoughts? (and corrections please!)

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera