Re: Review request, HBASE-8458 Support for batch version of checkAndMutate()

Could someone please take a look at this? On Tue, May 5, 2020 at 8:03 AM Toshihiro Suzuki wrote: > Hi folks! > > Could someone please review the following Jira and PR? Actually this > feature is important for our use case. > > HBASE-8458 Support for batch version of checkAndMutate(): >

Review request, HBASE-8458 Support for batch version of checkAndMutate()

Hi folks! Could someone please review the following Jira and PR? Actually this feature is important for our use case. HBASE-8458 Support for batch version of checkAndMutate(): https://issues.apache.org/jira/browse/HBASE-8458 The RP: https://github.com/apache/hbase/pull/1648 The highlights of

Re: Review request, HBASE-11062

I've been reviewing Toshihiro's work. It is great. The feature is really sweet. I have two concerns that are up on the PR so won't repeat here. I'd be interested on what others think of the items raised. Thanks, S On Tue, Aug 20, 2019 at 8:46 AM Toshihiro Suzuki wrote: > Hi folks! > >

Re: Review request, HBASE-11062

+1 for putting into hbase-operator-tools Also plan to review, but need to find time (this week) On Tue, Aug 20, 2019 at 9:40 AM Sean Busbey wrote: > This looks excellent! I've added the PR to my queue for some time I > have put aside on Friday. > > Quick question, I see the PR is working

Re: Review request, HBASE-11062

This looks excellent! I've added the PR to my queue for some time I have put aside on Friday. Quick question, I see the PR is working against the main project repo. Could we put it in the hbase-operator-tools repo instead? given the nice abstraction cut point of using ClusterStatus it seems like

Review request, HBASE-11062

Hi folks! Currently, I'm working on hbtop that is a real-time monitoring tool for HBase like Unix's top command: https://issues.apache.org/jira/browse/HBASE-11062 It will be appreciated if anyone can spare some cycles to give reviews. The details of hbtop is as follows:

Review Request, HBASE-21255

Hi team, Recently, i'm working on codes related to ACLs module, and HBASE-21255 is the first one. It will be appreciated if anyone can spare some cycles to give reviews. Many thanks! -- Best regards, R.C

Re: Review request: improving our downstream dependency profile

On Tue, Jun 12, 2018 at 4:23 PM, Mike Drob wrote: > How does this impact the size of our releases and artifacts? Is that > already addressed on one of the issues? > HBASE-20615 discusses it the most, but doesn't get into the current specifics. It mentions that the shaded client jars will add

Re: Review request: improving our downstream dependency profile

How does this impact the size of our releases and artifacts? Is that already addressed on one of the issues? On Tue, Jun 12, 2018 at 4:05 PM, Sean Busbey wrote: > Hi folks! > > I've got 4/5 of the subtasks under HBASE-20331 "clean up shaded > packaging for 2.1" wrapped up and ready if folks

Review request: improving our downstream dependency profile

Hi folks! I've got 4/5 of the subtasks under HBASE-20331 "clean up shaded packaging for 2.1" wrapped up and ready if folks could take the time to review. The current set of commits all build on each other, there are 5 in total: * HBASE-20332 shaded mapreduce module shouldn't include hadoop *

docs review request HBASE-20072

Could a committer take a few minutes to review the changes here: https://issues.apache.org/jira/browse/HBASE-20072 1.1 has been EOM for coming up on 3 months and this jira updates our docs to better reflect that.

review request for our nightly test infra

Hi folks! Our Mike Drob reminded me this morning that the planned ASF Jenkins upgrade that removes jdk7 support is this weekend. (old thread for details: https://s.apache.org/FPJ5) As mentioned in the thread, this will remove our ability to rely on the current jdk7 nightly runs in branch-1. I

Re: Review request

Thanks a lot Ted, I will take look at remaining two issues. Regards Samir On Sat, Nov 28, 2015 at 1:20 AM, Ted Yu wrote: > HBASE-14523 has been integrated. > > The other two are close. > > Cheers > > On Fri, Nov 27, 2015 at 12:40 PM, Samir Ahmic >

Re: Review request

HBASE-14523 has been integrated. The other two are close. Cheers On Fri, Nov 27, 2015 at 12:40 PM, Samir Ahmic wrote: > Hi all, > > I'm trying to do some testing around > https://issues.apache.org/jira/browse/HBASE-14749 but i'm constantly > hitting some of these

Review request

Hi all, I'm trying to do some testing around https://issues.apache.org/jira/browse/HBASE-14749 but i'm constantly hitting some of these issues: https://issues.apache.org/jira/browse/HBASE-14462 https://issues.apache.org/jira/browse/HBASE-14523 https://issues.apache.org/jira/browse/HBASE-14531

Review request for HBASE-13743

We had a user get bit by this so I'd like to get HBASE-13743 into 0.98.14, first RC planned for tomorrow. It's going to hold up the RC until it goes in. Can I get a reviewer for this? I'm not getting clean precommit builds and can't tell if it is Jenkins noise (TestImportExport is notorious since

Review Request 4884: Backport HBASE-12533: staging directories are not deleted after secure bulk load

--- This is an automatically generated e-mail. To reply, visit: https://review.cloudera.org/r/4884/ --- Review request for hbase. Repository: hbase Description --- Summarizing

Re: Review Request 4884: Backport HBASE-12533: staging directories are not deleted after secure bulk load

. To reply, visit: https://review.cloudera.org/r/4884/ --- (Updated Feb. 4, 2015, 9:55 p.m.) Review request for hbase. Repository: hbase Description --- Summarizing discussion on HBASE-12533: Looks like

Review Request 4777: Add login code to HBase Canary tool.

--- This is an automatically generated e-mail. To reply, visit: https://review.cloudera.org/r/4777/ --- Review request for hbase. Repository: hbase Description --- Also

Re: Re: review request: HBASE-7403 Online Merge

On Sat, Mar 16, 2013 at 7:25 AM, Chunhui Shen zju...@163.com wrote: Kevin, Could we repair overlapping regions by hbck now, except offline merge? I think not, if so, please tell me the issue, thanks hbck has two options to repair overlapping regions -- either merge them or sideline them so

review request: HBASE-7403 Online Merge

Hi, On behalf of Chunhui, I am requesting review for HBASE-7403 Online Merge. This JIRA was created 3 months ago. Chunhui has responded to review comments very promptly, including a major rewrite around the time split transaction was rewritten. This feature has widely been requested. I feel the

Re: review request: HBASE-7403 Online Merge

Hi Ted, I jut gave it a look. I have updated it on the RB. Overall, this is very good and I'm eager to see that integrated! I'm waiting for this feature since the beginning ;) Regarding non adjacent regions merge? Will the system still be consistent after that? Or will hbck report some regions

Re:Re: review request: HBASE-7403 Online Merge

Hey,JM, When regions exist hole or overlap, administrator could merge non adjacent regions to keep table consistency, otherwise we shouldn't merge non adjacent regions. I would point this out in the annotation Thanks for the review Chunhui At 2013-03-16 20:52:48,Jean-Marc Spaggiari

Re: review request: HBASE-7403 Online Merge

Chunhui replied to this question on review board. Basically the force option is to repair overlapping regions or table with hole in its regions. Personally I think online merge should detect merging regions with hole in between them and not require force flag in that case because logically

Re: review request: HBASE-7403 Online Merge

Ted, Why would we use that merge tool when hbck will repair that? Should we throw a warning and tell the user to run repair first? On Mar 16, 2013 9:17 AM, Ted yuzhih...@gmail.com wrote: Chunhui replied to this question on review board. Basically the force option is to repair overlapping

Re: review request: HBASE-7403 Online Merge

Kevin: I have a few thoughts on your questions. But I think we should give Chunhui a chance to answer these questions first. Btw the improvement in handling region split by Enis is fairly new. Meaning hbck hasn't utilized this new model yet. Cheers On Mar 16, 2013, at 6:21 AM, Kevin O'dell

Re:Re: review request: HBASE-7403 Online Merge

Kevin, Could we repair overlapping regions by hbck now, except offline merge? I think not, if so, please tell me the issue, thanks Regarding non adjacent regions merge, we will throw the exception as the following: +if (!forcible !HRegionInfo.areAdjacent(regionStateA.getRegion(), +

Re: Review request for HBASE-7692: Ordered byte[] serialization

On Thu, Feb 21, 2013 at 7:23 PM, Enis Söztutar e...@apache.org wrote: BTW, I also think that we need to have a SQL-type to java type to byte[] layer, but that is another discussion. Say more Enis (either here or in a new thread). It would just be types? Would it be in this Orderly

Re: Review request for HBASE-7692: Ordered byte[] serialization

On Fri, Feb 22, 2013 at 10:48 AM, Nick Dimiduk ndimi...@gmail.com wrote: On Fri, Feb 22, 2013 at 10:14 AM, Matt Corgan mcor...@hotpads.com wrote: Not quite true. It makes use of Bytes and ImmutableBytesWritable from hbase-common. Oh, interesting. Could we inline the code from

Re: Review request for HBASE-7692: Ordered byte[] serialization

On Fri, Feb 22, 2013 at 5:40 PM, Nick Dimiduk ndimi...@gmail.com wrote: I think we're getting ahead of ourselves a bit here. First and foremost, I'm looking for consensus that HBase should ship with tools for serializing Java primitive types such that the byte[] representations maintain sorted

Re: Review request for HBASE-7692: Ordered byte[] serialization

On Fri, Feb 22, 2013 at 6:04 PM, Matt Corgan mcor...@hotpads.com wrote: All sounds fine to me Nick. I had not looked into the internals enough to realize Builders were optional. Sorry if I'm looking too far down the road, but the future implications of including such low level building

Re: Review request for HBASE-7692: Ordered byte[] serialization

You're absolutely correct: this library introduces client-side conventions and is not needed from within the HMaster or RegionServer. Is the consensus that it should reside in it's own module or be a sibling to the o.a.h.hbase.client source tree? I'm a little confused by the current state of the

Re: Review request for HBASE-7692: Ordered byte[] serialization

Elliot is working on making hbase-client module concrete in hbase-7012. Cheers On Feb 22, 2013, at 6:13 AM, Nick Dimiduk ndimi...@gmail.com wrote: You're absolutely correct: this library introduces client-side conventions and is not needed from within the HMaster or RegionServer. Is the

Re: Review request for HBASE-7692: Ordered byte[] serialization

Nick, I'm +1 for it having its own module, and being a sibling of hbase-client. I'm assuming the client stuff will happen before we release 0.96 since it has been started. Jon. On Fri, Feb 22, 2013 at 6:13 AM, Nick Dimiduk ndimi...@gmail.com wrote: You're absolutely correct: this library

Re: Review request for HBASE-7692: Ordered byte[] serialization

Yep the client will be fully separated as soon as rpc changes are stabilized. Until then keeping up the move patch was just too onerous. On Fri, Feb 22, 2013 at 6:31 AM, Jonathan Hsieh j...@cloudera.com wrote: Nick, I'm +1 for it having its own module, and being a sibling of hbase-client.

Re: Review request for HBASE-7692: Ordered byte[] serialization

To nitpick a little it wouldn't quite be a sibling of hbase-client because hbase-client depends on hbase-common and hbase-protocol while this new one will not depend on anything. Would hbase-server be able to see it? Would it basically be a standalone module being maintained by HBase? Also,

Re: Review request for HBASE-7692: Ordered byte[] serialization

+1 on all Matt's comments --- Jesse Yates @jesse_yates jyates.github.com On Fri, Feb 22, 2013 at 10:00 AM, Matt Corgan mcor...@hotpads.com wrote: To nitpick a little it wouldn't quite be a sibling of hbase-client because hbase-client depends on hbase-common and hbase-protocol

Re: Review request for HBASE-7692: Ordered byte[] serialization

Inline. On Fri, Feb 22, 2013 at 10:00 AM, Matt Corgan mcor...@hotpads.com wrote: To nitpick a little it wouldn't quite be a sibling of hbase-client because hbase-client depends on hbase-common and hbase-protocol while this new one will not depend on anything. Would hbase-server be able to

Re: Review request for HBASE-7692: Ordered byte[] serialization

Not quite true. It makes use of Bytes and ImmutableBytesWritable from hbase-common. Oh, interesting. Could we inline the code from Bytes.java and somehow get rid of the ImmutableBytesWritable. Like calling packages can add ImmutableBytesWritable functionality on top if they want to? Seems

Re: Review request for HBASE-7692: Ordered byte[] serialization

On Fri, Feb 22, 2013 at 10:14 AM, Matt Corgan mcor...@hotpads.com wrote: Not quite true. It makes use of Bytes and ImmutableBytesWritable from hbase-common. Oh, interesting. Could we inline the code from Bytes.java and somehow get rid of the ImmutableBytesWritable. Like calling

Re: Review request for HBASE-7692: Ordered byte[] serialization

Thanks Nick for carrying this through. My pledge to reviewers: if you disagree with putting orderly in its own module, please express your idea now. On Fri, Feb 22, 2013 at 11:37 AM, Nick Dimiduk ndimi...@gmail.com wrote: I'm working through the code that will produce a patch placing orderly

Re: Review request for HBASE-7692: Ordered byte[] serialization

On Fri, Feb 22, 2013 at 10:00 AM, Matt Corgan mcor...@hotpads.com wrote: To nitpick a little it wouldn't quite be a sibling of hbase-client because hbase-client depends on hbase-common and hbase-protocol Actually, quite the contrary. I don't see this as being an external module as much as

Re: Review request for HBASE-7692: Ordered byte[] serialization

I think I misspoke slightly but basically agree with Matt's notion that this would end up being the place to pickup the orderly jar and that ideally it has no hbase-* dependencies. I actually feel that the hbase-orderly module is a sibling to hbase-common and hbase-client. My initial thought is

Re: Review request for HBASE-7692: Ordered byte[] serialization

I agree with Jonathan that ideally this would not depend on hbase or hadoop. Could we just replace Hadoop's BytesWritable with a new class that does the same thing? I also have a concern about the way it builds the multi-field byte[] by allocating somewhat expensive Builder objects, etc. It's

Re: Review request for HBASE-7692: Ordered byte[] serialization

I think we're getting ahead of ourselves a bit here. First and foremost, I'm looking for consensus that HBase should ship with tools for serializing Java primitive types such that the byte[] representations maintain sorted order. This is primarily to the benefit of users of HBase in that 3rd party

Re: Review request for HBASE-7692: Ordered byte[] serialization

All sounds fine to me Nick. I had not looked into the internals enough to realize Builders were optional. Sorry if I'm looking too far down the road, but the future implications of including such low level building blocks could be hard to unwind. Worth a little discussion at least. On Fri,

Review request for HBASE-7692: Ordered byte[] serialization

Hi everyone, I'm of the opinion that HBase should provide a mechanism for serializing common java types such that the serialized format sorts according the the natural ordering of the type. I think many application efforts end up building a custom, partial implementation of this kind of

Re: Review request for HBASE-7692: Ordered byte[] serialization

Nick, While I believe having an order-preserving canonical serialization is a good idea, from doing a read of the mail and a skim of the jira it is not clear to my why this is inside hbase as part of hbase-common. Why isn't this part of a library on top of hbase (a dependency for Pig/Hive)

Re: Review request for HBASE-7692: Ordered byte[] serialization

I think this belongs in core HBase, as a replacement to Bytes, which should be deprecated eventually. We have a Bytes utility which is supposed to convert basic java types to byte[]'s, but it does not work for signed numbers. We already know that all of the clients, Hive, Pig, Phoenix, have to

Re: Review request for HBASE-7692: Ordered byte[] serialization

...@cloudera.com To: dev@hbase.apache.org Sent: Thursday, February 21, 2013 3:04 PM Subject: Re: Review request for HBASE-7692: Ordered byte[] serialization Nick, While I believe having an order-preserving canonical serialization is a good idea,  from doing a read of the mail and a skim of the jira

Re: Review request for HBASE-7692: Ordered byte[] serialization

So I buy the argument about this being included in hbase, but several of the questions still stand -- Why is this part of hbase-common? shouldn't this be just a dependency of hbase-client module? Does the hbase-server side need to depend on this? Since this is a large import of a currently

Re: review request: HBASE-5416 Improve performance of scans with some kind of filters

Max ran TestJoinedScanners, the performance test on linux server, test also finished successfully: [INFO] -- -- [INFO] BUILD SUCCESS [INFO] [INFO] Total

review request: HBASE-5416 Improve performance of scans with some kind of filters

Hi, Max Lapan has shown big improvement in this JIRA. He has been running this enhancement at his company. Here is request on review board: https://reviews.apache.org/r/5225 Thanks

Re: Coprocessor blog review request

Yes. 3 articles were posted there. We can certainly move them all if the contents are non-obsolete. May take some time to review and adjust(the coprocessor one changed quite bit). -mingjie On 01/25/2012 05:54 PM, Enis Söztutar wrote: Great!. Can we also export other non-obsolete blog

Coprocessor blog review request

Hi hbase devs. There used to be a hbase blog at http://hbaseblog.com/2010/11/30/hbase-coprocessors/ , however the server is no longer available. Since We also agreed to move all the blogs to apache weblog, I recovered the content of the post and made adjustments to reflect the changes

Re: Coprocessor blog review request

Great!. Can we also export other non-obsolete blog entries. Enis On Wed, Jan 25, 2012 at 5:10 PM, Mingjie Lai m...@apache.org wrote: Hi hbase devs. There used to be a hbase blog at http://hbaseblog.com/2010/11/**30/hbase-coprocessors/http://hbaseblog.com/2010/11/30/hbase-coprocessors/ ,

Re: a feature branch sounds like a great idea, but... (was Re: Code review request for hbase-4120 table priority)

@hbase.apache.org Cc: Andrew Purtell apurt...@apache.org Sent: Tuesday, December 13, 2011 11:57 AM Subject: Re: Code review request for hbase-4120 table priority Note: I've only done a quick look at the jira and the code. The high level design document/approach seems reasonable and I think most agree

Re: a feature branch sounds like a great idea, but... (was Re: Code review request for hbase-4120 table priority)

) - Original Message - From: Jonathan Hsieh j...@cloudera.com To: dev@hbase.apache.org Cc: Andrew Purtell apurt...@apache.org Sent: Tuesday, December 13, 2011 11:57 AM Subject: Re: Code review request for hbase-4120 table priority Note: I've only done a quick look at the jira

Re: a feature branch sounds like a great idea, but... (was Re: Code review request for hbase-4120 table priority)

...@gmail.com To: dev@hbase.apache.org Cc: Andrew Purtell apurt...@apache.org Sent: Friday, December 16, 2011 11:43 AM Subject: Re: a feature branch sounds like a great idea, but... (was Re: Code review request for hbase-4120 table priority) Jonathan: If the feature is very big and cannot be partitioned, I

a feature branch sounds like a great idea, but... (was Re: Code review request for hbase-4120 table priority)

- From: Jonathan Hsieh j...@cloudera.com To: dev@hbase.apache.org Cc: Andrew Purtell apurt...@apache.org Sent: Tuesday, December 13, 2011 11:57 AM Subject: Re: Code review request for hbase-4120 table priority Note: I've only done a quick look at the jira and the code.  The high level

Re: a feature branch sounds like a great idea, but... (was Re: Code review request for hbase-4120 table priority)

: Tuesday, December 13, 2011 11:57 AM Subject: Re: Code review request for hbase-4120 table priority Note: I've only done a quick look at the jira and the code. The high level design document/approach seems reasonable and I think most agree that this is a useful feature and that a lot

Re: Code review request for hbase-4120 table priority

On Mon, Dec 12, 2011 at 11:23 PM, lars hofhansl lhofha...@yahoo.com wrote: While I haven't looked (in depth) at the patch, yet, this is definitely a feature that will be extremely helpful for Salesforce's multitenant architecture to isolate tenants and services from each other. While we

Re: Code review request for hbase-4120 table priority

manageable for me - personally - to review the code. -- Lars - Original Message - From: Todd Lipcon t...@cloudera.com To: dev@hbase.apache.org; Andrew Purtell apurt...@apache.org Cc: Sent: Monday, December 12, 2011 4:55 PM Subject: Re: Code review request for hbase-4120

Re: Code review request for hbase-4120 table priority

On Tue, Dec 13, 2011 at 11:57 AM, Jonathan Hsieh j...@cloudera.com wrote: Note: I've only done a quick look at the jira and the code.  The high level design document/approach seems reasonable and I think most agree that this is a useful feature and that a lot of effort has gone into it.

Feature branch Was: Code review request for hbase-4120 table priority

; Andrew Purtell apurt...@apache.org Cc: Sent: Monday, December 12, 2011 4:55 PM Subject: Re: Code review request for hbase-4120 table priority On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell apurt...@apache.org wrote: HBase as a project should not have as a criteria for inclusion

Re: Feature branch Was: Code review request for hbase-4120 table priority

Subject: Re: Code review request for hbase-4120 table priority On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell apurt...@apache.org wrote: HBase as a project should not have as a criteria for inclusion of some feature that Cloudera and SU and Facebook run it. Core managed to escape Yahoo

Code review request for hbase-4120 table priority

Hi, 4120 has gone through more than 20 revisions. Please provide your comments. I plan to integrate it this week. Thanks

Re: Code review request for hbase-4120 table priority

On Mon, Dec 12, 2011 at 6:43 AM, yuzhih...@gmail.com wrote: Hi, 4120 has gone through more than 20 revisions. Please provide your comments. I plan to integrate it this week. I'd suggest hold on commit until some other committers have had a looksee. This is an important feature that we

Re: Code review request for hbase-4120 table priority

Waiting for review comments from other committers. The implementation is pluggable by using coprocessors. Cheers On Dec 12, 2011, at 5:43 PM, Stack st...@duboce.net wrote: On Mon, Dec 12, 2011 at 6:43 AM, yuzhih...@gmail.com wrote: Hi, 4120 has gone through more than 20 revisions.

Re: Code review request for hbase-4120 table priority

If it's completely a coprocessor, then it seems we should let it bake on github and only incorporate in core if we find that a number of the core HBase users are using it in production. Am I misunderstanding the implementation? (haven't looked at the most recent patch) -Todd On Mon, Dec 12, 2011

Re: Code review request for hbase-4120 table priority

- From: Todd Lipcon t...@cloudera.com To: dev@hbase.apache.org Cc: Sent: Monday, December 12, 2011 4:03 PM Subject: Re: Code review request for hbase-4120 table priority If it's completely a coprocessor, then it seems we should let it bake on github and only incorporate in core if we find

Re: Code review request for hbase-4120 table priority

This feature is used in production at Taobao (China's EBay). You can find related description about cluster size, etc on the Jira. My understanding for hbase-4120 is that we are making the code conform to Apache hbase standard. There is related change for web UI, etc. Without clear feedback

Re: Code review request for hbase-4120 table priority

) - Original Message - From: Andrew Purtell apurt...@apache.org To: dev@hbase.apache.org dev@hbase.apache.org Cc: Sent: Monday, December 12, 2011 4:30 PM Subject: Re: Code review request for hbase-4120 table priority HBASE-4120 deals with only the RPC prioritization parts. This cannot

Re: Code review request for hbase-4120 table priority

On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell apurt...@apache.org wrote: HBase as a project should not have as a criteria for inclusion of some feature that Cloudera and SU and Facebook run it. Core managed to escape Yahoo. Let's not run history in reverse here in HBase land. And,

Re: Code review request for hbase-4120 table priority

I will be supporting table priority and related changes in the foreseeable future. Cheers On Dec 12, 2011, at 6:55 PM, Todd Lipcon t...@cloudera.com wrote: On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell apurt...@apache.org wrote: HBase as a project should not have as a criteria for

Re: Code review request for hbase-4120 table priority

On Mon, Dec 12, 2011 at 4:30 PM, Andrew Purtell apurt...@apache.org wrote: I've become aware of several private forks of HDFS and HBase. Too bad. A pooling of dev resources would have almost surely have been better. BTW, to this point -- some of the private forks of HDFS and HBase are due to

Re: Code review request for hbase-4120 table priority

of attack prove their worth by hitting back. - Piet Hein (via Tom White) - Original Message - From: Todd Lipcon t...@cloudera.com To: dev@hbase.apache.org; Andrew Purtell apurt...@apache.org Cc: Sent: Monday, December 12, 2011 4:55 PM Subject: Re: Code review request for hbase-4120

Re: Code review request for hbase-4120 table priority

I would really like to see the isolation feature in 0.94+, so I intend to work with Jia and, if there is a successful result, support it going forward in a manner like Stargate, even though I may not run it personally (like I don't run Stargate). I take an expansive view of what open source

Re: Code review request for hbase-4120 table priority

I would expect that a committer wanting to use this feature in his company for production would do a much more thorough analysis than I did. I haven't looked at the patch yet. This is early, would be for 0.94 and 0.92 isn't even out yet, etc. Why make this personal? There are other open

Re: Code review request for hbase-4120 table priority

On Mon, Dec 12, 2011 at 10:14 PM, Andrew Purtell apurt...@yahoo.com wrote: There are other open source projects out there that aren't used for as critical data and would love to have that next feature that might differentiate them. Message received. A new level of maturity. Go elsewhere. Am

Re: Code review request for hbase-4120 table priority

No that's not correct. I believe I was told off by Nicolas and Taobao should look to contribute elsewhere, new features to some other open source project. On Dec 12, 2011, at 10:24 PM, Stack st...@duboce.net wrote: On Mon, Dec 12, 2011 at 10:14 PM, Andrew Purtell apurt...@yahoo.com wrote:

Re: Code review request for hbase-4120 table priority

: Sent: Monday, December 12, 2011 4:55 PM Subject: Re: Code review request for hbase-4120 table priority On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell apurt...@apache.org wrote: HBase as a project should not have as a criteria for inclusion of some feature that Cloudera and SU and Facebook run

patch review request : HBASE_4440 (adding presplit option to PerformanceEvaluation)

Hi devs, Patch attached. Feedback welcome https://issues.apache.org/jira/browse/HBASE-4440 thanks a lot Sujee http://sujee.net

Re: review request: HBASE-4508 Backport HBASE-3777 (connection sharing) to 0.90 branch

I plan to integrate latest patch to 0.90 branch this weekend. Pleas share your comments if you haven't done so. Cheers On Wed, Oct 19, 2011 at 9:19 PM, Ted Yu yuzhih...@gmail.com wrote: Joanthan: Your patch for 0.90 was submitted when I wrote my first email. Actually Bright's patch for

Re: review request: HBASE-4508 Backport HBASE-3777 (connection sharing) to 0.90 branch

Sounds good to me. That's basically why I posted separate versions. Thanks, Jon. On Wed, Oct 19, 2011 at 9:19 PM, Ted Yu yuzhih...@gmail.com wrote: Joanthan: Your patch for 0.90 was submitted when I wrote my first email. Actually Bright's patch for HBASE-4508 fixes the bug you mentioned by

review request: HBASE-4344 and 4345

Hi, See patch v9 up on HBASE-4344 and https://reviews.apache.org/r/1997/ It covers 4344 and 4345. Here is the execution time of test suite for patch v9: [INFO] Total time: 112 minutes 32 seconds The above is about 14 minutes shorter than that for patch v7. Your review comments are welcome.

review request for HBASE-3229

Jonathan: Can you review what Ming has done in HBASE-3229 to see if your original plan is implemented ? Thanks

Review Request: Speedup LoadIncrementalHFiles

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/572/ --- Review request for hbase and Todd Lipcon. Summary --- I refactored

Review Request: When HTable instance is discarded in putTable(), we should call tableFactory.releaseHTableInterface()

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/573/ --- Review request for hbase and Lars George. Summary --- Currently

Re: Review Request: Improvements to Hbck and better error reporting

email from ReviewBoard was blocked as spam. Re: https://issues.apache.org/jira/browse/HBASE-3695http://review.cloudera.org/r/1661/ Marc -- Forwarded message -- From: Marc Limotte mslimo...@gmail.com Date: Wed, Mar 23, 2011 at 4:16 PM Subject: Review Request: Improvements

Fwd: Review Request: Improvements to Hbck and better error reporting

mslimo...@gmail.com Date: Wed, Mar 23, 2011 at 4:16 PM Subject: Review Request: Improvements to Hbck and better error reporting To: Marc Limotte mslimo...@gmail.com, jirapos...@review.cloudera.org, dev@hbase.apache.org This is an automatically generated e-mail. To reply, visit: http

Review Request: Coprocessor Protocol Generic Support

--- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/1405/ --- Review request for hbase. Summary --- Coprocessors currently do

Re: Review Request: Coprocessor Protocol Generic Support

--- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/1405/ --- (Updated 2010-12-31 17:45:56.197941) Review request for hbase. Changes

Re: Review Request: HBASE-2312: Rename HLog Dir when Splitting

/ --- (Updated 2010-12-21 19:06:32) Review request for hbase. Summary --- There is a very corner case when bad things could happen(ie data loss): 1) RS #1 is going to roll its HLog - not yet created the new one, old one will get no more writes 2) RS #1 enters GC Pause of Death 3

Review Request: HBASE-3256: Coprocessors: Coprocessor host and observer for HMaster

--- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/1321/ --- Review request for hbase, stack, Andrew Purtell, and Jonathan Gray. Summary

Re: Review Request: HBASE-3256: Coprocessors: Coprocessor host and observer for HMaster

/ --- (Updated 2010-12-20 18:04:33) Review request for hbase, stack, Andrew Purtell, and Jonathan Gray. Summary --- This patch adds a new MasterObserver interface with pre/post hooks provided for operations defined

Re: Review Request: HBASE-3256: Coprocessors: Coprocessor host and observer for HMaster

wrote: --- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/1321/ --- (Updated 2010-12-20 18:04:33) Review request for hbase, stack

Re: Review Request: hbase-3362 If .META. offline between OPENING and OPENED, then wrong server location in .META. is possible

/ --- (Updated 2010-12-15 16:14:27) Review request for hbase and Jonathan Gray. Summary --- M src/main/java/org/apache/hadoop/hbase/regionserver/handler/OpenRegionHandler.java Removed stale comments and TODOs. Added a 'version' datamenber, the znode edit version which we keep across

Re: Review Request: hbase-3362 If .META. offline between OPENING and OPENED, then wrong server location in .META. is possible

/ --- (Updated 2010-12-15 16:14:27) Review request for hbase and Jonathan Gray. Summary --- M src/main/java/org/apache/hadoop/hbase/regionserver/handler/OpenRegionHandler.java Removed stale comments and TODOs. Added a 'version

Review Request: HBASE-3260: Add explicit lifecycle methods to Coprocessor interface

--- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/1306/ --- Review request for hbase, stack and Andrew Purtell. Summary --- This patch

  1   2   3   4   5   6   7   >