hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: querying hbase
Date Sun, 02 Jun 2013 10:59:55 GMT
On Sat, Jun 1, 2013 at 8:15 PM, Michael Segel <michael_segel@hotmail.com>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)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message