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

Switch to Threaded View
HBase >> mail # user >> querying hbase


Copy link to this message
-
Re: querying hbase
On Sat, Jun 1, 2013 at 8:15 PM, Michael Segel <[EMAIL PROTECTED]>wrote:

> What happens when you restart the RS?
>

I think 1) the master is given a heads-up, 2) all of the regions are
closed, 3) the JVM is bounced and everything is reloaded, 4) the RS comes
back up and checks in with the master, 5) the master reassigns all regions
and they are opened, and 6) the RS is back online. This would not change
from how a rolling restart is done today except with less churn.
> Suppose I'm running a scan on a completely different table and you restart
> the RS?
> What happens to me?
>

The client is either riding over a period of administrative unavailability
or failing the scan, depending on settings.

It's obvious why this would be unsatisfying. However, coprocessors are
system extensions tightly bound with HBase internals. The current model is
a CP upgrade is an HBase jar upgrade, in effect.  Considering changing this
model is a fine discussion to have, but let's be clear about what we want
to achieve. So far I hear the aim is hot code replacement. As far as I
know, JVMs only support that through the debugging interface (one JVM
transmits class bits to another), classes and interface signatures can't
change, and it is method by method replacement. OSGi can finesse a bundle
replacement by using a new classloader, but this means again classes and
interfaces shared between the bundle and everybody else can't change
signatures, and if both old and new bundle impls are somehow active at the
same time, their objects won't test as expected for equality, so still
somehow the old bundle must shut down / deregister from everything so its
objects aren't hanging around. Someone please correct me if I have this
wrong somehow.

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)