[jira] [Created] (HBASE-13535) Regions unassigned

stack created HBASE-13535: - Summary: Regions unassigned Key: HBASE-13535 URL: https://issues.apache.org/jira/browse/HBASE-13535 Project: HBase Issue Type: Bug Reporter: stack hbase-1.1

Re: HBCK question: Exception in checkRegionConsistency() would kill HBCK

How about collecting IOException's in checkRegionConsistencyConcurrently() and wrap them in MultipleIOException: /** Encapsulate a list of {@link IOException} into an {@link IOException} */ public class MultipleIOException extends IOException { Cheers On Wed, Apr 22, 2015 at 3:52 PM, Stephen J

[jira] [Created] (HBASE-13534) Change HBase master WebUI to explicitly mention if it is a backup master

Apekshit Sharma created HBASE-13534: --- Summary: Change HBase master WebUI to explicitly mention if it is a backup master Key: HBASE-13534 URL: https://issues.apache.org/jira/browse/HBASE-13534 Projec

Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2) is available. Please vote by April 24 2015

On Apr 22, 2015 4:40 PM, "Enis Söztutar" wrote: > > I think the agreement is to continue with the RC. > > > One note... in the japi report, I was a little surprised when I noticed > method additions to InterfaceAudience.Public annotated classes. This means > that a user could write code against 1.

HBCK question: Exception in checkRegionConsistency() would kill HBCK

I am looking the code at HBaseFsck#checkRegionConsistency(). It checks region consistency and repair the corruption if requested. However, this function expects some exceptions. For example, in one aspect of region repair, it calls HBaseFsckRepair#waitUntilAssigned(), if a region is in transitio

Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2) is available. Please vote by April 24 2015

I think the agreement is to continue with the RC. > One note... in the japi report, I was a little surprised when I noticed method additions to InterfaceAudience.Public annotated classes. This means that a user could write code against 1.0.1 that would not work against 1.0.0 which seems undesirabl

Re: Spinning up for 1.1 Release

I would love to see https://issues.apache.org/jira/browse/HBASE-13260 in if possible. Enis On Wed, Apr 22, 2015 at 12:49 PM, rajeshb...@apache.org < chrajeshbab...@gmail.com> wrote: > I would like to have it https://issues.apache.org/jira/browse/HBASE-13431 > in. > > On Thu, Apr 23, 2015 at 1:10

Re: JIRA reply threading

Consider it harmful? That's fine by me, I'll stop using it right now. On Wed, Apr 22, 2015 at 2:21 PM, Nick Dimiduk wrote: > The whole feature is frustrating. Makes it hard to track the conversation > without scanning al over the place. > > On Wed, Apr 22, 2015 at 2:06 PM, Andrew Purtell > wrot

Re: JIRA reply threading

The whole feature is frustrating. Makes it hard to track the conversation without scanning al over the place. On Wed, Apr 22, 2015 at 2:06 PM, Andrew Purtell wrote: > Yeah, maybe I had an issue with some assets failing to load. That's messy > > On Wed, Apr 22, 2015 at 1:26 PM, Sean Busbey wrote

[jira] [Created] (HBASE-13533) section on configuring ~/.m2/settings.xml has no anchor

Nick Dimiduk created HBASE-13533: Summary: section on configuring ~/.m2/settings.xml has no anchor Key: HBASE-13533 URL: https://issues.apache.org/jira/browse/HBASE-13533 Project: HBase Issue

[jira] [Resolved] (HBASE-11758) Meta region location should be cached

[ https://issues.apache.org/jira/browse/HBASE-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-11758. Resolution: Duplicate > Meta region location should be cached > ---

Re: JIRA reply threading

Yeah, maybe I had an issue with some assets failing to load. That's messy On Wed, Apr 22, 2015 at 1:26 PM, Sean Busbey wrote: > no I can't reproduce the behavior now, it's definitely still threaded when > I'm logged out. the html looks like it should also still work if some > assets fail to load

[jira] [Created] (HBASE-13532) Make UnknownScannerException logging less scary

Apekshit Sharma created HBASE-13532: --- Summary: Make UnknownScannerException logging less scary Key: HBASE-13532 URL: https://issues.apache.org/jira/browse/HBASE-13532 Project: HBase Issue T

Re: JIRA reply threading

no I can't reproduce the behavior now, it's definitely still threaded when I'm logged out. the html looks like it should also still work if some assets fail to load from CDN. On Wed, Apr 22, 2015 at 3:18 PM, Mikhail Antonov wrote: > I can't really say why existing responses aren't threaded if yo

Re: JIRA reply threading

I can't really say why existing responses aren't threaded if you aren't logged in, it doesn't need session information. On Wed, Apr 22, 2015 at 1:13 PM, Sean Busbey wrote: > Not present if you aren't logged in, also existing responses not threaded > if you aren't logged in, I think? > > Still can

Re: JIRA reply threading

Not present if you aren't logged in, also existing responses not threaded if you aren't logged in, I think? Still can't stand the implementation. On Wed, Apr 22, 2015 at 3:09 PM, Andrew Purtell wrote: > Is it just me or are the 'Reply' links for threading replies on JIRA > sometimes present and

JIRA reply threading

Is it just me or are the 'Reply' links for threading replies on JIRA sometimes present and sometimes not ? -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)

Re: Spinning up for 1.1 Release

I would like to have it https://issues.apache.org/jira/browse/HBASE-13431 in. On Thu, Apr 23, 2015 at 1:10 AM, Jerry He wrote: > You have my attention all the time, Nick :-) > We need the folks to get an agreement on HBASE-13149. Sean, Andy, Enis? > Of course the last resort is we do nothing bu

[jira] [Created] (HBASE-13531) After 4/18/15 merge, we have started encountering failures of TestAcidGuarantees#testMobScanAtomicity

Jonathan Hsieh created HBASE-13531: -- Summary: After 4/18/15 merge, we have started encountering failures of TestAcidGuarantees#testMobScanAtomicity Key: HBASE-13531 URL: https://issues.apache.org/jira/browse/HBAS

Re: Spinning up for 1.1 Release

You have my attention all the time, Nick :-) We need the folks to get an agreement on HBASE-13149. Sean, Andy, Enis? Of course the last resort is we do nothing but document it with manual workaround or manual jar replacement in 1.1. I am available to do any verification if there is any proposal.

Re: Spinning up for 1.1 Release

I'd love to have in if no one objects. On Wed, Apr 22, 2015 at 7:51 PM, Nick Dimiduk wrote: > My mistake Jerry, you're correct. My pre-coffee brain was thinking that by > upgrading Hadoop we'd promote the version of Jackson under us. This is no

Re: Spinning up for 1.1 Release

My mistake Jerry, you're correct. My pre-coffee brain was thinking that by upgrading Hadoop we'd promote the version of Jackson under us. This is not the case because we have an explicit dependency (though maybe maven is promoting this for us for the builds anyway?) Point is, we have issues that n

Re: Spinning up for 1.1 Release

Hi, Nick I probably missed something here. Upgrading to hadoop 2.6 would help HBASE-13149? >> HBASE-13149 and HBASE-13339 are making a strong argument for us to bump >> the Hadoop version to 2.6 for this release. Jerry

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

Andy -- I understood your intent, but thanks for clarifying. (as well as taking the time to break this discussion out in the first place). I agree with your assessment. re: Sean's comments, if it wasn't clear by me asking in the first place, I also think sticking as close as possible to semver

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

I'd much rather we stick with the definitions used in Semantic Versioning. Our use is already confusing enough given our matrix of compatibilities that don't get "major version for breaking" protections. We've previously discussed how we'll do additional minor releases when there's sufficient inte

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

Just to clarify something, I've proposed edits that clarify the de-facto practice, since additional methods are turning up in patch releases, but am not taking a position. So far we don't have consensus. > + HBase uses Semantic Versioning for its release versioning with a caveat that methods and

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

While I can understand the desire to want to add things, I do think it makes things harder for users to reliably write code against versions of HBase which (by their view) should be completely compatible with one another. Take this extremely hypothetical situation: I'm new to HBase and start

Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

I think these changes are Okay. On Wed, Apr 22, 2015 at 9:29 AM, Andrew Purtell wrote: > [Subject changed] > > On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser wrote: > > > I was a little surprised when I noticed method additions to > > InterfaceAudience.Public annotated classes. This means that a u

Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))

[Subject changed] On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser wrote: > I was a little surprised when I noticed method additions to > InterfaceAudience.Public annotated classes. This means that a user could > write code against 1.0.1 that would not work against 1.0.0 which seems > undesirable for

Re: Spinning up for 1.1 Release

Let me get HBASE-13452, as I spent some time looking at this code before. -M On Wed, Apr 22, 2015 at 9:16 AM, Nick Dimiduk wrote: > All, > > We're now just **two days away** from my proposed RC date! That means we're > very close to "pencils down" on new features for 1.1. > > I believe most of t

Re: Spinning up for 1.1 Release

All, We're now just **two days away** from my proposed RC date! That means we're very close to "pencils down" on new features for 1.1. I believe most of the major features we had outstanding have landed. The notable exception being HBASE-11339 MOB. I think Jon is close to calling a merge vote for

[jira] [Created] (HBASE-13530) Add param for bulkload wait duration in HRegion.

Victor Xu created HBASE-13530: - Summary: Add param for bulkload wait duration in HRegion. Key: HBASE-13530 URL: https://issues.apache.org/jira/browse/HBASE-13530 Project: HBase Issue Type: Improv

[jira] [Created] (HBASE-13529) Procedure v2 - WAL Improvements

Matteo Bertozzi created HBASE-13529: --- Summary: Procedure v2 - WAL Improvements Key: HBASE-13529 URL: https://issues.apache.org/jira/browse/HBASE-13529 Project: HBase Issue Type: Sub-task