[jira] [Reopened] (HBASE-7928) Scanning .META. with startRow and/or stopRow is not giving proper results

[ https://issues.apache.org/jira/browse/HBASE-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl reopened HBASE-7928: -- > Scanning .META. with startRow and/or stopRow is not giving proper results > -

[jira] [Resolved] (HBASE-7973) API changes between 0.92.1 and 0.94.2 breaking downstream API

[ https://issues.apache.org/jira/browse/HBASE-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik resolved HBASE-7973. --- Resolution: Invalid Apparently, there's a way to work around this change in the clien

Re: Weekend Reading : Table Locks

I read the zookeeper recipe page and then corelated your implementation with that during this week. Anyway thanks for the doc too :) Regards Ram On Sat, Mar 2, 2013 at 9:17 AM, Ted Yu wrote: > bq. master operations acquiring locks for every region, and region splits > acquiring the region lock

Build failed in Jenkins: HBase-0.94 #874

See Changes: [ramkrishna] HBASE-7928 Scanning .META. with startRow and/or stopRow is not giving proper results (Ram) -- [...truncated 2254 lines...] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,

Re: Weekend Reading : Table Locks

bq. master operations acquiring locks for every region, and region splits acquiring the region lock for their region Can you elaborate how the above conclusion was drawn ? Looks like region split is not categorized as master operation. To my knowledge, region split requires coordination on master

Re: [DISCUSS] More new feature backports to 0.94.

I did mean "stablizing". What I was trying to point is that stuff we backport might stabilize HBase. From: Ted Yu To: dev@hbase.apache.org; lars hofhansl Sent: Friday, March 1, 2013 7:30 PM Subject: Re: [DISCUSS] More new feature backports to 0.94. bq. Tha

Build failed in Jenkins: HBase-TRUNK #3908

See -- [...truncated 3699 lines...] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.542 sec Running org.apache.hadoop.hbase.regionserver.TestFSErrorsExposed Tests run: 3, Failures: 0, Error

Re: [DISCUSS] More new feature backports to 0.94.

bq. That is only if we do not backport stabilizing "features". Did you mean destabilizing above :-) My preference is option #1. With option #2, the community would be dealing with one more branch which would increase the amount of work validating each release candidate. To me, the difference betw

Re: [DISCUSS] More new feature backports to 0.94.

That is only if we do not backport stabilizing "features". There is an "opportunity cost" to be paid if we take a too rigorous approach too. Take for example table-locks (which prompted this discussion). With that in place we can do safe online schema changes (that won't fail and leave the tab

Re: [DISCUSS] More new feature backports to 0.94.

That is only if we do not backport stabilizing "features". There is an "opportunity cost" to be paid if we take a too rigorous approach too. Take for example table-lock (which prompted this discussion). With that in place we can do safe online schema upgrade (that won't fail and leave the table

Re: [DISCUSS] More new feature backports to 0.94.

That is only if we do not backport stabilizing "features". There is an "opportunity cost" to be paid if we take a too rigorous approach too. Take for example table-lock (which prompted this discussion). With that in place we can do safe online schema upgrade (that won't fail and leave the table

[jira] [Created] (HBASE-7978) Merge hbase-prefixtree into hbase-server

Enis Soztutar created HBASE-7978: Summary: Merge hbase-prefixtree into hbase-server Key: HBASE-7978 URL: https://issues.apache.org/jira/browse/HBASE-7978 Project: HBase Issue Type: Improvemen

Re: Weekend Reading : Table Locks

Thanks for documenting that Enis. I was wondering what to do tonight ;) JM 2013/3/1 Enis Söztutar : > If you are bored this weekend, you can take a look at the table locks doc, > that I attached at HBASE-7305. > > There has been a lot of confusion about the current status, design and > implementa

Re: [DISCUSS] More new feature backports to 0.94.

@Lars: No, not any concern about anything already backported. Just a preference to #2 because it seems to make things more stable and easier to manage. New feature = new release. Given new sub-releases are for fixes and improvements, but not new features. Also, if we backport a feature in one or ma

Build failed in Jenkins: hbase-0.95 #10

See -- [...truncated 3917 lines...] Running org.apache.hadoop.hbase.util.hbck.TestOfflineMetaRebuildOverlap Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 27.381 sec Running org.apache.hadoop.hb

Re: [DISCUSS] More new feature backports to 0.94.

I think the current way of risk vs rewards analysis is working well. We will just continue doing that on a case by case basis, discussing the implications on individual issues. On Fri, Mar 1, 2013 at 6:46 PM, Lars Hofhansl wrote: > BTW are you concerned about any specific back port we did in t

Weekend Reading : Table Locks

If you are bored this weekend, you can take a look at the table locks doc, that I attached at HBASE-7305. There has been a lot of confusion about the current status, design and implementation, for which I take the blame. Hope these notes help to answer the questions. If not, leave a note here, an

Re: [DISCUSS] More new feature backports to 0.94.

BTW are you concerned about any specific back port we did in the past? So far we have not seen any destabilization in any of the 0.94 releases. Jean-Marc Spaggiari wrote: >Hi Lars, #2, does it mean you will stop back-porting the new features >when it will become a "long-term" release? If so, I'

Re: [DISCUSS] More new feature backports to 0.94.

Yes. That's the idea. #1 does not mean that we "milli-vanilli" back port random things into 0.94. We'll weigh the pros and the risks and decide based on that. My personal preference is indeed option #1, but as I said I'd volunteer to make #2 happen. -- Lars Jean-Marc Spaggiari wrote: >Hi L

Re: [DISCUSS] More new feature backports to 0.94.

Hi Lars, #2, does it mean you will stop back-porting the new features when it will become a "long-term" release? If so, I'm for option #2... JM In your option 2013/3/1 Enis Söztutar : > Thanks Lars, I think it is a good listing of the options we have. > > I'll be +1 for #1 and #2, with #1 being a

Re: [DISCUSS] More new feature backports to 0.94.

+1 on option #1. +0 on option #2. On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl wrote: > So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we > have three options: > 1. Backport new features to 0.94 as we see fit as long as we do not > destabilize 0.94. > 2. Declare a certain

Re: [DISCUSS] More new feature backports to 0.94.

Thanks Lars, I think it is a good listing of the options we have. I'll be +1 for #1 and #2, with #1 being a preference. Enis On Fri, Mar 1, 2013 at 6:10 PM, lars hofhansl wrote: > So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we > have three options: > 1. Backport new

Re: [DISCUSS] More new feature backports to 0.94.

So it seems that until we have a stable 0.96 (maybe 0.96.1 or 0.96.2) we have three options: 1. Backport new features to 0.94 as we see fit as long as we do not destabilize 0.94. 2. Declare a certain point release (0.94.6 looks like a good candidate) as a "long term", create an 0.94.6 branch (in

[jira] [Created] (HBASE-7977) Online merge should acquire table lock

Enis Soztutar created HBASE-7977: Summary: Online merge should acquire table lock Key: HBASE-7977 URL: https://issues.apache.org/jira/browse/HBASE-7977 Project: HBase Issue Type: Improvement

[jira] [Created] (HBASE-7976) Rest of master operations (move, assign, unassign, offline region) should also acquire table locks

Enis Soztutar created HBASE-7976: Summary: Rest of master operations (move, assign, unassign, offline region) should also acquire table locks Key: HBASE-7976 URL: https://issues.apache.org/jira/browse/HBASE-7976

Re: [DISCUSS] More new feature backports to 0.94.

I think we have discussed this before, and your concerns are valid. In the snapshot backporting discussions, I have proposed to do fork 94, and add snapshots on top of it, and make a release called 0.95 (0.95 wasn't being used back then). The conclusion from those discussions was that, if I rememb

[jira] [Created] (HBASE-7975) ImportTsv documentation update for table creation

Nick Dimiduk created HBASE-7975: --- Summary: ImportTsv documentation update for table creation Key: HBASE-7975 URL: https://issues.apache.org/jira/browse/HBASE-7975 Project: HBase Issue Type: Bra

[jira] [Created] (HBASE-7974) CompleteBulkLoad should handle hfile permissions more gracefully

Nick Dimiduk created HBASE-7974: --- Summary: CompleteBulkLoad should handle hfile permissions more gracefully Key: HBASE-7974 URL: https://issues.apache.org/jira/browse/HBASE-7974 Project: HBase

[jira] [Created] (HBASE-7973) API changes between 0.92.1 and 0.94.2 breaking downstream API changes

Konstantin Boudnik created HBASE-7973: - Summary: API changes between 0.92.1 and 0.94.2 breaking downstream API changes Key: HBASE-7973 URL: https://issues.apache.org/jira/browse/HBASE-7973 Project

Re: [DISCUSS] More new feature backports to 0.94.

I also think also that new features need to go in new versions only and try to avoid backporting them.. Else if we keep adding new features in previous versions, we might have to keep adding bug fixes because of those features and it's a never ending story. But as Elliott is saying, we need to pus

Re: [DISCUSS] More new feature backports to 0.94.

I think we are basically agreeing -- my primary concern is bringing new features in vital paths introduces more risk, I'd rather not backport major new features unless we achieve a higher level of assurance through system and basic fault injection testing. For the three current examples -- snapsho

Re: [DISCUSS] More new feature backports to 0.94.

I'm worried about users who are starting to use 0.94.x. If they have a bug in that version, and it's fixed or they submit a patch to fix it. Then they should have a version to upgrade to that includes that bug fix and doesn't include other new features. I don't think that many people will want

Re: New member: Trying to submit a patch

On Fri, Mar 1, 2013 at 1:42 PM, Shivendra Singh < shivendra.p.si...@oracle.com> wrote: > Hi Everyone, > > I am a new member of the group. > I have a patch which compiles fine with the uni tests disabled, but with > the tests enabled I am getting, following error: > testNodeHealthChore(org.**apache

[jira] [Resolved] (HBASE-7500) TestNodeHealthCheckChore occasionally fails in trunk build

[ https://issues.apache.org/jira/browse/HBASE-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-7500. -- Resolution: Invalid Marking invalid hoping it fixed by HBASE-7951 > TestNodeHealthCheckChore o

New member: Trying to submit a patch

Hi Everyone, I am a new member of the group. I have a patch which compiles fine with the uni tests disabled, but with the tests enabled I am getting, following error: testNodeHealthChore(org.apache.hadoop.hbase.TestNodeHealthCheckChore) Time elapsed: 0.03 sec <<< FAILURE! java.lang.AssertionE

[jira] [Created] (HBASE-7972) Add a configuration for the TCP backlog in the Thrift server

Jean-Daniel Cryans created HBASE-7972: - Summary: Add a configuration for the TCP backlog in the Thrift server Key: HBASE-7972 URL: https://issues.apache.org/jira/browse/HBASE-7972 Project: HBase

[jira] [Created] (HBASE-7971) mvn compile on trunk and 0.95 does not produce target/cached_classpath.txt

Nick Dimiduk created HBASE-7971: --- Summary: mvn compile on trunk and 0.95 does not produce target/cached_classpath.txt Key: HBASE-7971 URL: https://issues.apache.org/jira/browse/HBASE-7971 Project: HBase

[jira] [Created] (HBASE-7970) Improve file descriptor usage: Currently, there are two fds per one storefile

Himanshu Vashishtha created HBASE-7970: -- Summary: Improve file descriptor usage: Currently, there are two fds per one storefile Key: HBASE-7970 URL: https://issues.apache.org/jira/browse/HBASE-7970

Re: [DISCUSS] More new feature backports to 0.94.

This is an open source project, as long as there is a volunteer to backport a patch I see no problem with doing this. The only thing we as the community should ensure is that it must be demonstrated that the patch does not destabilize the 0.94 code base; that has to be done on a case by case bas

Re: [DISCUSS] More new feature backports to 0.94.

+1 to all of this. Additionally, please keep in mind that when we backport something now, we have to backport it to both 0.95 and 0.94. - Dave On Fri, Mar 1, 2013 at 8:31 AM, Jonathan Hsieh wrote: > I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also > saw HBASE-7965 wh

[DISCUSS] More new feature backports to 0.94.

I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also saw HBASE-7965 which suggests porting some major-ish features (table locks, online merge) in to the apache 0.94 line. We should chat about what we want to do about new features and bringing them into stable versions (0.94

Build failed in Jenkins: HBase-TRUNK-on-Hadoop-2.0.0 #426

See -- [...truncated 21868 lines...] Running org.apache.hadoop.hbase.security.access.TestAccessController Tests run: 35, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 49.29 sec Forking comm

Build failed in Jenkins: hbase-0.95-on-hadoop2 #7

See -- [...truncated 21956 lines...] Running org.apache.hadoop.hbase.rest.client.TestRemoteAdmin Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.869 sec Forking command line: /bin/sh

[jira] [Created] (HBASE-7969) Rename HBaseAdmin#getCompletedSnapshots as HBaseAdmin#listSnapshots

Ted Yu created HBASE-7969: - Summary: Rename HBaseAdmin#getCompletedSnapshots as HBaseAdmin#listSnapshots Key: HBASE-7969 URL: https://issues.apache.org/jira/browse/HBASE-7969 Project: HBase Issue Ty

Build failed in Jenkins: HBase-0.94 #873

See -- [...truncated 2256 lines...] Running org.apache.hadoop.hbase.mapreduce.TestTableMapReduce Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 176.381 sec Running org.apache.hadoop.hbase.mapre