Sure, but that wont change the fact that Coprocessors should go under a massive rewrite. You're hitting a problem that Sybase faced while Informix (datablades) didn't when it came to running end user code within the engine. But I'm dating myself...
On Jun 1, 2013, at 3:20 PM, James Taylor <[email protected]> wrote: > These approaches all sound somewhat brittle and unlikely to be relied on for > a production system (more here: > https://issues.apache.org/jira/browse/HBASE-8607). Sounds like a rolling > restart is the best option in the near/medium term. Our pain points are more > around how to get to the point where Phoenix can more easily be installed. > Maybe https://issues.apache.org/jira/browse/HBASE-8400 would help? > > I propose we move the discussion to those JIRAs. > > On 06/01/2013 11:15 AM, Michael Segel wrote: >> Well, >> >> What happens when you restart the RS? >> >> Suppose I'm running a scan on a completely different table and you restart >> the RS? >> What happens to me? >> >> I havent thought through the whole problem, but you need to put each table's >> CP in to its own sandbox. >> (There's more to it and would require some pizza, beer and a very large >> whiteboard....) >> >> >> On Jun 1, 2013, at 5:44 AM, Andrew Purtell <[email protected]> wrote: >> >>> Isn't the time to restart and the steps necessary more or less the same? Or >>> will the objects that hold the in memory state survive across the reload? >>> Will they still share a classloader (maintain equality tests)? What if the >>> implementation / bundle version changes? We are taking about an upgrade >>> scenario. Will we need to dump and restore in memory state to local disk, >>> pickle the state of an earlier version and have the latest version >>> unpickle, fixing up as needed? What happens if that fails midway? >>> The JITted code for the old bundle is unused and GCed now that the bundle >>> is upgraded, so we have to wait for runtime profiling and C2 to crunch the >>> bytecode again for the new bundle. Will all that need more time than just >>> restating a JVM ? Am I missing a simpler way? >>> >>> On Saturday, June 1, 2013, Michel Segel wrote: >>> >>>>> Is there a benefit to restarting a regionserver in an OSGi container >>>> versus >>>>> restarting a Java process? >>>> Was that rhetorical? >>>> >>>> Absolutely. >>>> Think of a production environment where you are using HBase to serve data >>>> in real time. >>>> >>>> >>>> Sent from a remote device. Please excuse any typos... >>>> >>>> Mike Segel >>>> >>>> On May 24, 2013, at 4:50 PM, Andrew Purtell >>>> <[email protected]<javascript:;>> >>>> wrote: >>>> >>>>> On Thu, May 23, 2013 at 5:10 PM, James Taylor >>>>> <[email protected]<javascript:;> >>>>> wrote: >>>>> >>>>>> Has there been any discussions on running the HBase server in an OSGi >>>>>> container? >>>>> >>>>> I believe the only discussions have been on avoiding talk about >>>> coprocessor >>>>> reloading, as it implies either a reimplementation of or taking on an >>>> OSGi >>>>> runtime. >>>>> >>>>> Is there a benefit to restarting a regionserver in an OSGi container >>>> versus >>>>> restarting a Java process? >>>>> >>>>> Or would that work otherwise like an update the coprocessor and filters >>>> in >>>>> the container then trigger the embedded regionserver to do a quick close >>>>> and reopen of the regions? >>>>> >>>>> -- >>>>> Best regards, >>>>> >>>>> - Andy >>>>> >>>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>>>> (via Tom White) >>> >>> -- >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>> (via Tom White) > >
