Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Please welcome Ramkrishna, our newest hbase committer. Ram has been going great guns fixing ugly hbase bugs with a good while now. I'm glad he's on board. Good on you Ram, St.Ack

Build failed in Jenkins: HBase-TRUNK #2263

See https://builds.apache.org/job/HBase-TRUNK/2263/ -- [...truncated 1654 lines...] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 33.958 sec Running org.apache.hadoop.hbase.regionserver.TestScanner Tests run: 6, Failures: 0, Errors: 0,

Re: Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Congrats! On Wed, Sep 28, 2011 at 9:15 AM, Stack st...@duboce.net wrote: Please welcome Ramkrishna, our newest hbase committer.  Ram has been going great guns fixing ugly hbase bugs with a good while now.  I'm glad he's on board. Good on you Ram, St.Ack

Re: Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Congrats Ramkrishna! :D On 28-Sep-2011, at 9:45 PM, Stack wrote: Please welcome Ramkrishna, our newest hbase committer. Ram has been going great guns fixing ugly hbase bugs with a good while now. I'm glad he's on board. Good on you Ram, St.Ack

backporting HBASE-3777 to 0.90

Hi, Bright Fulton has volunteered to backport HBASE-3777 to 0.90 I endorse his effort. If you have comment(s), please share. I will open a new JIRA for this effort if this motion passes. Thanks

Re: Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Great job Ram! First commit should be adding yourself here: http://hbase.apache.org/team-list.html J-D On Wed, Sep 28, 2011 at 9:15 AM, Stack st...@duboce.net wrote: Please welcome Ramkrishna, our newest hbase committer.  Ram has been going great guns fixing ugly hbase bugs with a good while

Re: backporting HBASE-3777 to 0.90

I'm -0 at the moment, it's a big patch to include in a point release. I'm glad the work was done tho because it means those interested (like me) can directly patch it in and test it (at my own risk). J-D On Wed, Sep 28, 2011 at 9:29 AM, Ted Yu yuzhih...@gmail.com wrote: Hi, Bright Fulton has

Re: backporting HBASE-3777 to 0.90

One reason for my endorsement is that it would take 0.92 quite some time to reach the level of stability of 0.90.4 I really think HBASE-3777 would benefit HBase users a lot, and reducing potential future inquiry about connection-related issues. Of course, backporting increases the amount of work

Re: Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Congrats Ram! Great work! On Wed, Sep 28, 2011 at 9:41 AM, Jean-Daniel Cryans jdcry...@apache.orgwrote: Great job Ram! First commit should be adding yourself here: http://hbase.apache.org/team-list.html J-D On Wed, Sep 28, 2011 at 9:15 AM, Stack st...@duboce.net wrote: Please welcome

Re: Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Welcome! On 9/28/11 12:15 PM, Stack st...@duboce.net wrote: Please welcome Ramkrishna, our newest hbase committer. Ram has been going great guns fixing ugly hbase bugs with a good while now. I'm glad he's on board. Good on you Ram, St.Ack

Re: Please welcome Ramkrishna S. Vasudevan, our newest hbase committer

Dear All Thanks a lot. Hope to do my best with all your guys support. :) Thanks once again. Regards Ram - Original Message - From: Doug Meil doug.m...@explorysmedical.com Date: Wednesday, September 28, 2011 11:55 pm Subject: Re: Please welcome Ramkrishna S. Vasudevan, our newest

Re: backporting HBASE-3777 to 0.90

+1 I volunteer to test the changes when a patch is ready.      - Andy - Original Message - From: Ted Yu yuzhih...@gmail.com To: dev@hbase.apache.org Cc: Sent: Wednesday, September 28, 2011 9:55 AM Subject: Re: backporting HBASE-3777 to 0.90 One reason for my endorsement is that

Re: backporting HBASE-3777 to 0.90

Changing the connection identity behavior in the middle of a release series seems like a bad idea. The 0.20 releases did connection identity based on Configuration contents, 0.90 changed this to Configuration instance identity, then 0.90.5 would be going back to contents again (acknowledged with

Build failed in Jenkins: HBase-0.92 #25

See https://builds.apache.org/job/HBase-0.92/25/changes Changes: [jgray] HBASE-4488 Store could miss rows during flush (Lars H via jgray) -- [...truncated 1648 lines...] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.667 sec Running

Re: backporting HBASE-3777 to 0.90

If anyone running 0.90 relies on the current behavior to enforce separate connections (for whatever reason), using separate Configuration instances, this would break that behavior and appear as a regression right? Does anyone do this? We could query user@ before considering commit. I agree

Re: backporting HBASE-3777 to 0.90

IMO ideal would be to somehow duplicate the codepaths - is it completely impossible to do so? Or could we hack in a flag like hbase.connpool.by.identity=true -- default to the broken way, and let users switch to the new codepath by toggling the boolean? Sorry I don't have enough context on the

Re: backporting HBASE-3777 to 0.90

default to the broken way LOL On Wed, Sep 28, 2011 at 12:24 PM, Todd Lipcon t...@cloudera.com wrote: IMO ideal would be to somehow duplicate the codepaths - is it completely impossible to do so? Or could we hack in a flag like hbase.connpool.by.identity=true -- default to the broken way, and

Re: backporting HBASE-3777 to 0.90

We could query user@ before considering commit. Let's do this. Objections ? On Wed, Sep 28, 2011 at 12:17 PM, Andrew Purtell apurt...@apache.orgwrote: If anyone running 0.90 relies on the current behavior to enforce separate connections (for whatever reason), using separate Configuration

Re: backporting HBASE-3777 to 0.90

On Thu, Sep 29, 2011 at 4:27 AM, Ted Yu yuzhih...@gmail.com wrote: We could query user@ before considering commit. Let's do this. Objections ? I don't think most users will know whether this will break them until it's too late. Hence defaulting to current behavior, and letting people switch

Re: backporting HBASE-3777 to 0.90

One option is to publish the backported patch which passes all unit tests and 'certified' by people who play trial on it. The switch proposed by Todd is nice but difficult to implement. Cheers On Wed, Sep 28, 2011 at 12:29 PM, Todd Lipcon t...@cloudera.com wrote: On Thu, Sep 29, 2011 at 4:27

Re: backporting HBASE-3777 to 0.90

I'd switch from -1 to +1 if we can get +1s from people who have tried it on clusters with several different real existing apps written by several different teams. EG if we can verify that the CIQ workload, the SU workload, and the TM workload all work with this patch with no adverse effects, seems

Re: backporting HBASE-3777 to 0.90

Bright wasn't aware of the discussion so far. Looks like we have two -1's, two +1's and one -0 On Wed, Sep 28, 2011 at 12:40 PM, Todd Lipcon t...@cloudera.com wrote: I'd switch from -1 to +1 if we can get +1s from people who have tried it on clusters with several different real existing apps

Jenkins build is back to normal : HBase-TRUNK #2264

See https://builds.apache.org/job/HBase-TRUNK/2264/changes

Re: backporting HBASE-3777 to 0.90

I'd switch from -1 to +1 if we can get +1s from people who have tried it on clusters with several different real existing apps written by several different teams. This makes sense. My +1 was partly an agreement that I'd try it. Best regards,    - Andy Problems worthy of attack prove

Re: backporting HBASE-3777 to 0.90

Thanks Andy for your support. Appreciate it. On Wed, Sep 28, 2011 at 1:39 PM, Andrew Purtell apurt...@apache.org wrote: I'd switch from -1 to +1 if we can get +1s from people who have tried it on clusters with several different real existing apps written by several different teams. This

Re: backporting HBASE-3777 to 0.90

I dont have power to vote. But if it helps, we are running with HBASE-3777 on top of 0.90.3 from the day it was committed. The qps on one of our data centers is 50K. On Wed, Sep 28, 2011 at 2:30 PM, Ted Yu yuzhih...@gmail.com wrote: Thanks Andy for your support. Appreciate it. On Wed, Sep

Re: backporting HBASE-3777 to 0.90

Shrijeet: I dont have power to vote. I don't think so. The fact that you have been using 3777 is the best vote. Please elaborate more on your cluster setup, usage pattern and whether your application needed to be twisted after the new build went in. Thanks On Wed, Sep 28, 2011 at 2:41 PM,

Forcing separate connections Was: backporting HBASE-3777 to 0.90

Gary: Karthick and I devised the following (HConstants.HBASE_CLIENT_INSTANCE_ID) for the scenario you listed below: /** * Parameter name for unique identifier for this {@link Configuration} * instance. If there are two or more {@link Configuration} instances that, * for all intents and

Re: backporting HBASE-3777 to 0.90

Ted, Please elaborate more on your cluster setup We have 10 RS nodes , 1 Master and 1 Zookeeper usage pattern and whether your Live writes and reads but super heavy on reads. Cache hit is pretty high. Application needed to be twisted after the new build went in. No we did not change anything in

Re: Forcing separate connections Was: backporting HBASE-3777 to 0.90

Hi Ted, Thanks for pointing it out. Looking through the patch I did see that forcing separate connections was supported by tweaking the instance ID value. The problem I'm pointing out is not that it can't be done, but that it would require code changes on the user's part. As an HBase user,

Re: backporting HBASE-3777 to 0.90

On Wed, Sep 28, 2011 at 1:39 PM, Andrew Purtell apurt...@apache.org wrote: I'd switch from -1 to +1 if we can get +1s from people who have tried it on clusters with several different real existing apps written by several different teams. This makes sense. My +1 was partly an agreement

Build failed in Jenkins: HBase-TRUNK #2265

See https://builds.apache.org/job/HBase-TRUNK/2265/changes Changes: [ramkrishna] -- [...truncated 1654 lines...] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 123.438 sec Running org.apache.hadoop.hbase.mapreduce.TestImportTsv Tests

Build failed in Jenkins: HBase-TRUNK-on-Hadoop-23 #42

See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-23/42/changes Changes: [ramkrishna] [dmeil] HBASE-4504 book.xml - filters [jgray] HBASE-4131 Make the Replication Service pluggable via a standard interface definition (dhruba via jgray) [jgray] HBASE-4488 Store could miss rows