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)
