[
https://issues.apache.org/jira/browse/HBASE-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-15079.
Resolution: Fixed
Fix Version/s: (was: 0.98.18)
> TestMultiParallel.validateLoad
I've been tracking some of these in HBASE-15006. Now that branch deletion
is enabled again, I'd love to start crossing them off.
On Fri, Feb 12, 2016 at 11:16 AM, Nick Dimiduk wrote:
> Devs,
>
> How are we handling the retirement of old release lines? ASF policy
> now requires all release tags b
[
https://issues.apache.org/jira/browse/HBASE-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John reopened HBASE-15079:
Reopening as I see test failures after commit of this Jira to 0.98
(No other fix branches have
Monday is a holiday.
Wednesday seems better for end of voting period.
On Fri, Feb 12, 2016 at 7:41 PM, Sean Busbey wrote:
> okay, I'll roll RC3 tomorrow.
>
> What are folks thinking on voting period? 72hrs (~tuesday)? Maybe Wednesday
> for a little extra?
>
> On Fri, Feb 12, 2016 at 7:07 PM, St
okay, I'll roll RC3 tomorrow.
What are folks thinking on voting period? 72hrs (~tuesday)? Maybe Wednesday
for a little extra?
On Fri, Feb 12, 2016 at 7:07 PM, Stack wrote:
> A longer ITBLL run passes so 1.2 HEAD is basically sound I'd say...
> St.Ack
>
> On Fri, Feb 12, 2016 at 1:22 PM, Stack
Duo Zhang created HBASE-15265:
-
Summary: Implement an asynchronous FSHLog
Key: HBASE-15265
URL: https://issues.apache.org/jira/browse/HBASE-15265
Project: HBase
Issue Type: Sub-task
R
Duo Zhang created HBASE-15264:
-
Summary: Implement a fan out HDFS OutputStream
Key: HBASE-15264
URL: https://issues.apache.org/jira/browse/HBASE-15264
Project: HBase
Issue Type: Sub-task
stack created HBASE-15263:
-
Summary:
TestIPv6NIOServerSocketChannel.testServerSocketFromLocalhostResolution can hang
indefinetly
Key: HBASE-15263
URL: https://issues.apache.org/jira/browse/HBASE-15263
Projec
stack created HBASE-15262:
-
Summary: TestZooKeeperMainServer#testCommandLineWorks fails with
CancelledKeyException
Key: HBASE-15262
URL: https://issues.apache.org/jira/browse/HBASE-15262
Project: HBase
A longer ITBLL run passes so 1.2 HEAD is basically sound I'd say...
St.Ack
On Fri, Feb 12, 2016 at 1:22 PM, Stack wrote:
> I just ran a small ITBLL against current 1.2 HEAD and it seems fine...
> nothing untoward in logs. Running bigger one now. Lets just go w/ tip of
> 1.2? And one of the items
huaxiang sun created HBASE-15261:
Summary: Make Throwable t in DaughterOpener volatile
Key: HBASE-15261
URL: https://issues.apache.org/jira/browse/HBASE-15261
Project: HBase
Issue Type: Bug
Also in the 0.98 history.
> On Feb 12, 2016, at 12:04 PM, Nick Dimiduk wrote:
>
>> On Fri, Feb 12, 2016 at 11:44 AM, Sean Busbey wrote:
>>
>> I *could* make 1.2.0 RC3 that just cherry picks HBASE-15252 onto RC2, but
>> that's going to make things a bit messy and possibly confusing for folks
>
I did some validation today.
See my comment at the tail of HBASE-15219.
I reverted my patch until we find out which patch caused the
-treatFailureAsError
flag not to work.
On Fri, Feb 12, 2016 at 1:22 PM, Stack wrote:
> I just ran a small ITBLL against current 1.2 HEAD and it seems fine...
> no
I just ran a small ITBLL against current 1.2 HEAD and it seems fine...
nothing untoward in logs. Running bigger one now. Lets just go w/ tip of
1.2? And one of the items just got reverted:
commit e52ac92b9810425cb5345121260959e4c0ad5ab3
Author: tedyu
Date: Fri Feb 12 12:01:45 2016 -0800
HB
On Fri, Feb 12, 2016 at 11:44 AM, Sean Busbey wrote:
> I *could* make 1.2.0 RC3 that just cherry picks HBASE-15252 onto RC2, but
> that's going to make things a bit messy and possibly confusing for folks
> who look for the 1.2.0 tag to be an ancestor of branch-1.2's HEAD.
>
We have no strict req
Lets just roll what's there. The removal of fas narrow seems easy enough.
Canary fixes wouldn't sink a release even if they were incorrect.
HFileReaderv2 prefetch, rpc codec, and the data loss seems like the ones
we'll need to focus on for testing. But that seems do-able.
On Fri, Feb 12, 2016 at 1
here is what has happened on branch-1.2 since RC2:
* 7ed1603 - (origin/branch-1.2) HBASE-15252 Data loss when replaying wal if
HDFS timeout (11 hours ago)
* 19d964d - HBASE-15198 RPC client not using Codec and CellBlock for puts
by default-addendum. (18 hours ago)
* cc863f3 - HBASE-15224 Undo "hba
I am in favor of "bug fixes only" changes to the patch releases. In 1.0
release lines, we tried to stick to that, and explicitly did not backport
some nice improvements. In many occasions, we had backported some issue
thinking that it is harmless, but turned out to be a problem. So, the less
change
Same here. I have started with RC2 but can mostly carry findings to RC3 given
only one additional change.
> On Feb 12, 2016, at 8:56 AM, Elliott Clark wrote:
>
> -1 until the dataloss is fixed.
>
> But assuming that's fixed I would be good for a short vote cycle for the
> next RC.
>
>> On Fr
I think if we tell people to drop the "0." prefix from pre 1.0 versions and
squint then it gives a good sense of what can and did happen release to
release.
> On Feb 12, 2016, at 10:23 AM, Jonathan Hsieh wrote:
>
> I agree with Andrew here.
>
> We had a good cadence with 98 -- I didn't mean
I agree with Andrew here.
We had a good cadence with 98 -- I didn't mean to exclude. The fast
cadence of 94/98 releases was good -- the more recent 1.x lines haven't
been as frequent.
Using the more precise terminology Andrew suggests-- if we used our new
versioning rules back in the 94/98 days
On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell
wrote:
> I think Elliott's point of view is spot on for patch releases and
> furthermore our semver-like policy as documented expresses that
> conservatism when discussing point releases.
>
Yeah my concern was really only for patch versions. We sho
If we go with shortened voting period, my assumption is that RC3 would be
RC2 + fix for HBASE-15252, right ?
Cheers
On Thu, Feb 11, 2016 at 9:18 PM, Sean Busbey wrote:
> On Thu, Feb 11, 2016 at 10:59 PM, Stack wrote:
>
> > On Thu, Feb 11, 2016 at 5:04 PM, Sean Busbey
> > wrote:
> >
> > > On F
I was responding to
(Jon) "One of the things about having frequent point release like when we had
with 0.94"
On Feb 12, 2016, at 9:33 AM, Nick Dimiduk wrote:
>>> One of the
>>> things about having frequent point release like when we had with 0.94 was
>>> that we likely could have shipped some
'Point release' isn't precise enough terminology. We have major, minor, and
patch releases:
0.96 -> 0.98 or 1.0 -> 2.0 - major
0.98.0 -> 0.98.1, or 1.0.0 -> 1.1.0 - minor
0.98.0 -> 0.98.0.1, or 1.0.0 -> 1.0.1 - patch
I think Elliott's point of view is spot on for patch releases and furthermore
Ankit Singhal created HBASE-15260:
-
Summary: Should we check zero length value in checkAndMutate when
null is passes as expected value?
Key: HBASE-15260
URL: https://issues.apache.org/jira/browse/HBASE-15260
I was speaking of the frequency of minor releases on the 1.x line, not 98.
On Friday, February 12, 2016, Andrew Purtell
wrote:
> We don't have frequent enough releases with 0.98?
>
>
> > On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh > wrote:
> >
> > Users also deserve to get as few new surprises
We don't have frequent enough releases with 0.98?
> On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh wrote:
>
> Users also deserve to get as few new surprises as possible. Being on the
> supporting side of this, I've come to prefer preserving minor known issues
> to having new unknown issues cause
[
https://issues.apache.org/jira/browse/HBASE-15219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reopened HBASE-15219:
This wasn't tested?
> Canary tool does not return non-zero exit code when one of regions is in
Devs,
How are we handling the retirement of old release lines? ASF policy
now requires all release tags be "permanent/archival", which is enforced by
pushing them to the 'rel' space. From my perspective, that means everything
else that's no longer under active development can be deleted. As a rece
-1 until the dataloss is fixed.
But assuming that's fixed I would be good for a short vote cycle for the
next RC.
On Fri, Feb 12, 2016 at 1:02 AM, 张铎 wrote:
> HBASE-15252 is fixed :).
>
> 2016-02-12 14:00 GMT+08:00 Stack :
>
> > -1
> >
> > The dataloss issue was just discovered. I think now we
Build status: Successful
If successful, the website and docs have been generated. If failed, skip to the
bottom of this email.
Use the following commands to download the patch and apply it to a clean branch
based on origin/asf-site. If you prefer to keep the hbase-site repo around
permanently,
Just a reminder that it would be great if a few people could review this
patch offering. If we can get HBase-oriented Maven archetypes publicly
available (via the Maven Central Repository), it might prove quite helpful
to new adopters (or those sites that are considering adoption) of HBase
technolo
[
https://issues.apache.org/jira/browse/HBASE-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-15252.
---
Resolution: Fixed
Pushed the addendum to 0.98.
> Data loss when replaying wal if HDFS timeout
>
[
https://issues.apache.org/jira/browse/HBASE-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang reopened HBASE-15252:
---
The patch for 0.98 breaks hadoop-1.1 compatibility.
> Data loss when replaying wal if HDFS timeout
> ---
HBASE-15252 is fixed :).
2016-02-12 14:00 GMT+08:00 Stack :
> -1
>
> The dataloss issue was just discovered. I think now we know of it, even
> though the incidence is rare, would be best to respin the RC.
>
> You the man Sean,
> St.Ack
>
>
> On Thu, Feb 11, 2016 at 8:59 PM, Stack wrote:
>
> > On
36 matches
Mail list logo
