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
Michael Segel 2013-06-02, 02:44
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)
>
>