Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> querying hbase


Copy link to this message
-
Re: querying hbase
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)
>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB