hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <michael_se...@hotmail.com>
Subject Re: querying hbase
Date Sun, 02 Jun 2013 02:44:00 GMT
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 <jtaylor@salesforce.com> 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 <apurtell@apache.org> 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 <apurtell@apache.org<javascript:;>>
>>>> wrote:
>>>> 
>>>>> On Thu, May 23, 2013 at 5:10 PM, James Taylor <jtaylor@salesforce.com<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)
> 
> 


Mime
View raw message