[jira] [Created] (HBASE-20415) branches-2 don't need maven-scala-plugin

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-20415:
---

 Summary: branches-2 don't need maven-scala-plugin
 Key: HBASE-20415
 URL: https://issues.apache.org/jira/browse/HBASE-20415
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 2.0.0
Reporter: Sean Busbey
Assignee: Sean Busbey


the spark support revert missed a couple of plugins in the top level pom for 
making sure we get scaladocs.

verified there is no scala in the source tree, so these plugins aren't needed.
{code}
hbase $ find . -name '*.scala'
hbase $ 
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [jira] [Created] (HBASE-20233) [metrics] Ill-formatted numRegions metric in "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean

[Ted Yu]

Hi,
I have added you as contributor.

Please upload patch.

Thanks

On Fri, Apr 13, 2018 at 4:28 PM, Xu Cang  wrote:

> Hi,
> This is a small patch for this issue. (first time trying to use Apache
> JIRA, it does not allow me to upload patch file. please let me know if this
> is the wrong way to send patches.)
>
> Best,
> Xu
>
>
>

Re: [jira] [Created] (HBASE-20233) [metrics] Ill-formatted numRegions metric in "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean

[Xu Cang]

Hi,
This is a small patch for this issue. (first time trying to use Apache
JIRA, it does not allow me to upload patch file. please let me know if this
is the wrong way to send patches.)

Best,
Xu

On Tue, Mar 20, 2018 at 1:05 PM, stack (JIRA)  wrote:

> stack created HBASE-20233:
> -
>
>  Summary: [metrics] Ill-formatted numRegions metric in
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean
>  Key: HBASE-20233
>  URL: https://issues.apache.org/jira/browse/HBASE-20233
>  Project: HBase
>   Issue Type: Bug
>   Components: metrics
>  Environment: Noticed this poking at metrics. The MBean
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" carries per region
> metrics. They are all formatted like so:
>
> {code}
> Namespace_default_table_IntegrationTestBigLinkedList_
> metric_incrementTime_98th_percentile: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_
> metric_incrementTime_99th_percentile: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_
> metric_incrementTime_99.9th_percentile: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_num_ops:
> 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_min:
> 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_max:
> 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_mean:
> 0,
> {code}
>
> In the middle of them all is a metric named...
> {code}
> numRegions: 15,
> {code}
>
> It has a different format and it is out of scope when compared to the
> other metrics in this mbean; it belongs better elsewhere, perhaps in the
> Server bean.
>
> I noticed it because it breaks the parse done by tcollector scraping our
> metrics from /jmx
>
> It was added long ago in HBASE-14166
> Reporter: stack
>
>
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>

[jira] [Created] (HBASE-20414) TestLockProcedure#testMultipleLocks may fail on slow machine

[Ted Yu (JIRA)]

Ted Yu created HBASE-20414:
--

 Summary: TestLockProcedure#testMultipleLocks may fail on slow 
machine
 Key: HBASE-20414
 URL: https://issues.apache.org/jira/browse/HBASE-20414
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu


Here was recent failure : 
https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/172/testReport/junit/org.apache.hadoop.hbase.master.locking/TestLockProcedure/health_checks___yetus_jdk8_hadoop2_checks___testMultipleLocks/
{code}
java.lang.AssertionError: expected: but was:
at 
org.apache.hadoop.hbase.master.locking.TestLockProcedure.sendHeartbeatAndCheckLocked(TestLockProcedure.java:221)
at 
org.apache.hadoop.hbase.master.locking.TestLockProcedure.testMultipleLocks(TestLockProcedure.java:311)
{code}
In the test output, we can see this:
{code}
2018-04-13 20:19:54,230 DEBUG [Time-limited test] 
locking.TestLockProcedure(225): Proc id 22 : LOCKED.
...
2018-04-13 20:19:55,529 DEBUG [Time-limited test] 
procedure2.ProcedureExecutor(865): Stored pid=26, state=RUNNABLE; 
org.apache.hadoop.hbase.master.locking.LockProcedure 
regions=a7f9adfd047350eabb199a39564ba4db,c1e297609590b707233a2f9c8bb51fa1, 
type=EXCLUSIVE

2018-04-13 20:19:56,230 DEBUG [ProcExecTimeout] locking.LockProcedure(207): 
Timeout failure ProcedureEvent for pid=22, state=WAITING_TIMEOUT; 
org.apache.hadoop.hbase.master.locking.LockProcedure, namespace=namespace, 
type=EXCLUSIVE, ready=false, [pid=22, state=WAITING_TIMEOUT; 
org.apache.hadoop.hbase.master.locking.LockProcedure, namespace=namespace, 
type=EXCLUSIVE]
{code}
After the pid=26 log, the code does this (1 second wait):
{code}
// Assert tables & region locks are waiting because of namespace lock.
Thread.sleep(HEARTBEAT_TIMEOUT / 2);
{code}

On a slow machine (in the case above), there was only 730 msec between the 
queueing of regionsLock2 and the WAITING_TIMEOUT state of the nsLock. The 1 
second wait was too long, leading to assertion failure.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20413) IntegrationTestRegionReplicaReplication fails

[stack (JIRA)]

stack created HBASE-20413:
-

 Summary: IntegrationTestRegionReplicaReplication fails
 Key: HBASE-20413
 URL: https://issues.apache.org/jira/browse/HBASE-20413
 Project: HBase
  Issue Type: Bug
  Components: test
Reporter: stack
 Fix For: 2.0.0


Following [~psomogyi]'s inspiration, I've been running unit tests on a GCE 
instance. IntegrationTestRegionReplicaReplication fails always for branch-2.0. 
It fails for branch-1 too but for a different looking reason. On branch-2.0, 
its OOME'ing. Downing the size of ingested data, it seems to hang unable to 
update because it is unable to flush.

Marking this a blocker for now. Fix or disable it for branch-2.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20412) Update our compliance-checker from 2.1 to 2.4

[stack (JIRA)]

stack created HBASE-20412:
-

 Summary: Update our compliance-checker from 2.1 to 2.4
 Key: HBASE-20412
 URL: https://issues.apache.org/jira/browse/HBASE-20412
 Project: HBase
  Issue Type: Bug
Reporter: stack


I thought we had an issue to do this already but I can't find it.

The newer compatibility-checker has the filtering on annotation added by one of 
us (or at least asked-for by one-of-us).

i tried it yesterday.  Seems to work nicely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20411) Ameliorate MutableSegment synchronize

[stack (JIRA)]

stack created HBASE-20411:
-

 Summary: Ameliorate MutableSegment synchronize
 Key: HBASE-20411
 URL: https://issues.apache.org/jira/browse/HBASE-20411
 Project: HBase
  Issue Type: Bug
Reporter: stack


This item is migrated from HBASE-20236 so it gets dedicated issue.

Let me upload evidence that has this synchronize as a stake in our write-time 
perf. I'll migrate the patch I posted with updates that come of comments posted 
by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Stack]

On Fri, Apr 13, 2018 at 10:53 AM, Josh Elser  wrote:

> Was poking around with PE on a few nodes (I forget the exact
> circumstances, need to look back at this), and ran into a case where ~35
> regions were left as RIT
>
> 2018-04-12 22:05:24,431 ERROR 
> [master/ctr-e138-1518143905142-221855-01-02:16000]
> procedure2.ProcedureExecutor: Corrupt pid=3580, ppid=3534,
> state=RUNNABLE:REGION_TRANSITION_QUEUE; AssignProcedure table=TestTable,
> region=71fef  ffe6b5b3cf1cb6d3328a5a58690
>
> Saw entries like this (I think) for each region which was stuck. A simple
> `assign` in the shell brought them back, but I need to dig in some more to
> understand what went wrong.
>
>
Log?

HBASE-18152?

Thanks Josh,
S




>
> On 4/10/18 4:47 PM, Stack wrote:
>
>> The first release candidate for Apache HBase 2.0.0 is available for
>> downloading and testing.
>>
>> Artifacts are available here:
>>
>>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
>>
>> Maven artifacts are available in the staging repository at:
>>
>>   https://repository.apache.org/content/repositories/orgapachehbase-1209
>>
>> All artifacts are signed with my signing key 8ACC93D2, which is also
>> in the project KEYS file at
>>
>>   http://www.apache.org/dist/hbase/KEYS
>>
>> These artifacts were tagged 2.0.0RC0 at
>> hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
>>
>> Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0
>> Reference Guide before installing or upgrading for a list of
>> incompatibilities, major changes, and notable new features. Be aware that
>> according to our adopted Semantic Versioning guidelines[1], we've allow
>> ourselves to make breaking changes in this major version release. For
>> example, Coprocessors will need to be recast to fit more constrained CP
>> APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x without
>> downtime is (currently) not possible. That said, a bunch of effort has
>> been
>> expended mitigating differences; a hbase-1.x client can perform DML
>> against
>> an hbase-2 cluster.
>>
>> For the full list of ~6k issues addressed, see [2]. There are also
>> CHANGES.md and RELEASENOTES.md in the root directory of the source
>> tarball.
>>
>> Please take a few minutes to verify the release and vote on releasing it:
>>
>> [ ] +1 Release this package as Apache HBase 2.0.0
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...
>>
>> This VOTE will run for one week and close Tuesday, April 17, 2018 @ 13:00
>> PST.
>>
>> Thanks to the myriad who have helped out with this release,
>> Your 2.0.0 Release Manager
>>
>> 1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
>> 2.  https://s.apache.org/zwS9
>>
>>

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Josh Elser]

Was poking around with PE on a few nodes (I forget the exact 
circumstances, need to look back at this), and ran into a case where ~35 
regions were left as RIT


2018-04-12 22:05:24,431 ERROR 
[master/ctr-e138-1518143905142-221855-01-02:16000] 
procedure2.ProcedureExecutor: Corrupt pid=3580, ppid=3534, 
state=RUNNABLE:REGION_TRANSITION_QUEUE; AssignProcedure table=TestTable, 
region=71fef  ffe6b5b3cf1cb6d3328a5a58690


Saw entries like this (I think) for each region which was stuck. A 
simple `assign` in the shell brought them back, but I need to dig in 
some more to understand what went wrong.


On 4/10/18 4:47 PM, Stack wrote:

The first release candidate for Apache HBase 2.0.0 is available for
downloading and testing.

Artifacts are available here:

  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/

Maven artifacts are available in the staging repository at:

  https://repository.apache.org/content/repositories/orgapachehbase-1209

All artifacts are signed with my signing key 8ACC93D2, which is also
in the project KEYS file at

  http://www.apache.org/dist/hbase/KEYS

These artifacts were tagged 2.0.0RC0 at
hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46

Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0
Reference Guide before installing or upgrading for a list of
incompatibilities, major changes, and notable new features. Be aware that
according to our adopted Semantic Versioning guidelines[1], we've allow
ourselves to make breaking changes in this major version release. For
example, Coprocessors will need to be recast to fit more constrained CP
APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x without
downtime is (currently) not possible. That said, a bunch of effort has been
expended mitigating differences; a hbase-1.x client can perform DML against
an hbase-2 cluster.

For the full list of ~6k issues addressed, see [2]. There are also
CHANGES.md and RELEASENOTES.md in the root directory of the source tarball.

Please take a few minutes to verify the release and vote on releasing it:

[ ] +1 Release this package as Apache HBase 2.0.0
[ ] +0 no opinion
[ ] -1 Do not release this package because...

This VOTE will run for one week and close Tuesday, April 17, 2018 @ 13:00
PST.

Thanks to the myriad who have helped out with this release,
Your 2.0.0 Release Manager

1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
2.  https://s.apache.org/zwS9

[jira] [Resolved] (HBASE-20224) Web UI is broken in standalone mode

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi resolved HBASE-20224.
---
Resolution: Fixed

Pushed addendum 4 and 5 to branch-2.0.

> Web UI is broken in standalone mode
> ---
>
> Key: HBASE-20224
> URL: https://issues.apache.org/jira/browse/HBASE-20224
> Project: HBase
>  Issue Type: Bug
>  Components: UI, Usability
>Affects Versions: 2.0.0-beta-2
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: 
> 0001-HBASE-20224-Web-UI-is-broken-in-standalone-mode-ADDE.ADDENDUM.patch, 
> 20224-addendum.3.txt, 20224.addendum.4, 20224.addendum.5, 20224.addendum.6, 
> hbase-20224.master.001.patch, hbase-20224.master.002.patch, 
> hbase-20224.master.003.patch, hbase-20224.master.addendum.patch
>
>
> Web UI doesn't show up in standalone mode on default port. This can be seen 
> on master and branch-2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Stack]

On Fri, Apr 13, 2018 at 8:07 AM, Peter Somogyi  wrote:

> -1
>
> Tests under hbase-rsgroup fail in setup phase. It is related to
> HBASE-20224, some addendums were not backported to branch-2.0 which causes
> the failure. I'm reopening HBASE-20224 and backport 2 missing commits.
>
>
Thanks Peter. Yeah, go for the backports. That issue was a bit of a mess.

I'm trying to see why we didn't catch this in the nightlies.

Lets not shut down the RC yet. I'd like to see if there are other issues
out there before cutting new RC.

Good stuff,
St.Ack





> On Fri, Apr 13, 2018 at 3:54 PM, Jean-Marc Spaggiari <
> jean-m...@spaggiari.org> wrote:
>
> > Exactly what I was looking for! Thanks Sean!
> >
> > 2018-04-13 9:37 GMT-04:00 Sean Busbey :
> >
> > > Hi JMS!
> > >
> > > Current flaky results for branch-2.0, generated today AFAICT:
> > >
> > > https://builds.apache.org/view/H-L/view/HBase/job/HBase-
> > > Find-Flaky-Tests-branch2.0/lastSuccessfulBuild/artifact/
> > >
> > > you can look at the "dashboard.html" artifact for a human usable idea
> > > of what we think is broken.
> > >
> > > you can fetch the excludes file to get a pattern you can pass to Maven.
> > >
> > >
> > > On Fri, Apr 13, 2018 at 7:40 AM, Jean-Marc Spaggiari
> > >  wrote:
> > > > Do we have a list of tests that we know will not pass this release?
> > > >
> > > > I got those failures so far, but since I want to run multiple runs, I
> > > want
> > > > to make sure to exclude the un-stable tests.
> > > >
> > > > TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152
> > Metrics
> > > > Should be equal expected:<1> but was:<0>
> > > > TestReplicationSmallTests.testDisableEnable:198 Replication wasn't
> > > disabled
> > > > TestReplicationSmallTests.testSimplePutDelete:168->
> > TestReplicationBase.
> > > runSimplePutDeleteTest:266
> > > > Waited too much time for put replication
> > > > TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
> > > > callDurat...
> > > >
> > > > Thanks,
> > > >
> > > > JMS
> > > >
> > > >
> > > > 2018-04-13 0:19 GMT-04:00 Yu Li :
> > > >
> > > >> bq. I'd imagine that if the difference were large, then yes, it
> should
> > > >> be a blocker
> > > >> -- or we as a community can decide to work on it in a follow-on
> > release
> > > >> making perf a priority (say, 2.1.0).
> > > >> I see, thanks for the clarification boss, makes sense.
> > > >>
> > > >> Best Regards,
> > > >> Yu
> > > >>
> > > >> On 13 April 2018 at 06:02, Stack  wrote:
> > > >>
> > > >> > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
> > > >> >
> > > >> > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey  >
> > > >> wrote:
> > > >> > >
> > > >> > >> no compat report in the RC directory. does that mean we won't
> > have
> > > one
> > > >> > >> in the dist area?
> > > >> > >>
> > > >> > >>
> > > >> > >> not a blocker; we've been inconsistent on it in prior releases,
> > but
> > > >> > >> the trend seemed to be towards including it.
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> > > HBASE-18622 has current state of compatibility compare. Let me
> do
> > a
> > > new
> > > >> > > run and add it to the RC dir.
> > > >> > >
> > > >> >
> > > >> > I just added
> > > >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > > >> > compat-check-v1.2.6-v2.0.0.report.html
> > > >> >
> > > >> > Thanks,
> > > >> > S
> > > >> >
> > > >> >
> > > >> >
> > > >> > > St.Ack
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >>
> > > >> > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack 
> wrote:
> > > >> > >> > The first release candidate for Apache HBase 2.0.0 is
> available
> > > for
> > > >> > >> > downloading and testing.
> > > >> > >> >
> > > >> > >> > Artifacts are available here:
> > > >> > >> >
> > > >> > >> >  https://dist.apache.org/repos/
> dist/dev/hbase/hbase-2.0.0RC0/
> > > >> > >> >
> > > >> > >> > Maven artifacts are available in the staging repository at:
> > > >> > >> >
> > > >> > >> >  https://repository.apache.org/content/repositories/
> > > >> > orgapachehbase-1209
> > > >> > >> >
> > > >> > >> > All artifacts are signed with my signing key 8ACC93D2, which
> is
> > > also
> > > >> > >> > in the project KEYS file at
> > > >> > >> >
> > > >> > >> >  http://www.apache.org/dist/hbase/KEYS
> > > >> > >> >
> > > >> > >> > These artifacts were tagged 2.0.0RC0 at
> > > >> > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
> > > >> > >> >
> > > >> > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled
> HBase
> > > 2.0.0
> > > >> > >> > Reference Guide before installing or upgrading for a list of
> > > >> > >> > incompatibilities, major changes, and notable new features.
> Be
> > > aware
> > > >> > >> that
> > > >> > >> > according to our adopted Semantic Versioning guidelines[1],
> > we've
> > > >> > allow
> > > >> > >> > ourselves to make breaking changes in this major 

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Stack]

On Fri, Apr 13, 2018 at 5:40 AM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> Do we have a list of tests that we know will not pass this release?
>
> I got those failures so far, but since I want to run multiple runs, I want
> to make sure to exclude the un-stable tests.
>
> TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152 Metrics
> Should be equal expected:<1> but was:<0>
> TestReplicationSmallTests.testDisableEnable:198 Replication wasn't
> disabled
> TestReplicationSmallTests.testSimplePutDelete:168->TestReplicationBase.
> runSimplePutDeleteTest:266
> Waited too much time for put replication
> TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
> callDurat...
>
>
Sorry about that JMS. We just had a nice set of stable runs but a little
bit of rot seems to have set in in the last day or so. Probably needs a
little attention to shut down the new set of flakies.

Thanks,
St.Ack



> Thanks,
>
> JMS
>
>
> 2018-04-13 0:19 GMT-04:00 Yu Li :
>
> > bq. I'd imagine that if the difference were large, then yes, it should
> > be a blocker
> > -- or we as a community can decide to work on it in a follow-on release
> > making perf a priority (say, 2.1.0).
> > I see, thanks for the clarification boss, makes sense.
> >
> > Best Regards,
> > Yu
> >
> > On 13 April 2018 at 06:02, Stack  wrote:
> >
> > > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
> > >
> > > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey 
> > wrote:
> > > >
> > > >> no compat report in the RC directory. does that mean we won't have
> one
> > > >> in the dist area?
> > > >>
> > > >>
> > > >> not a blocker; we've been inconsistent on it in prior releases, but
> > > >> the trend seemed to be towards including it.
> > > >>
> > > >>
> > > >
> > > > HBASE-18622 has current state of compatibility compare. Let me do a
> new
> > > > run and add it to the RC dir.
> > > >
> > >
> > > I just added
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > > compat-check-v1.2.6-v2.0.0.report.html
> > >
> > > Thanks,
> > > S
> > >
> > >
> > >
> > > > St.Ack
> > > >
> > > >
> > > >
> > > >>
> > > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack  wrote:
> > > >> > The first release candidate for Apache HBase 2.0.0 is available
> for
> > > >> > downloading and testing.
> > > >> >
> > > >> > Artifacts are available here:
> > > >> >
> > > >> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > > >> >
> > > >> > Maven artifacts are available in the staging repository at:
> > > >> >
> > > >> >  https://repository.apache.org/content/repositories/
> > > orgapachehbase-1209
> > > >> >
> > > >> > All artifacts are signed with my signing key 8ACC93D2, which is
> also
> > > >> > in the project KEYS file at
> > > >> >
> > > >> >  http://www.apache.org/dist/hbase/KEYS
> > > >> >
> > > >> > These artifacts were tagged 2.0.0RC0 at
> > > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
> > > >> >
> > > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase
> 2.0.0
> > > >> > Reference Guide before installing or upgrading for a list of
> > > >> > incompatibilities, major changes, and notable new features. Be
> aware
> > > >> that
> > > >> > according to our adopted Semantic Versioning guidelines[1], we've
> > > allow
> > > >> > ourselves to make breaking changes in this major version release.
> > For
> > > >> > example, Coprocessors will need to be recast to fit more
> constrained
> > > CP
> > > >> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x
> > > without
> > > >> > downtime is (currently) not possible. That said, a bunch of effort
> > has
> > > >> been
> > > >> > expended mitigating differences; a hbase-1.x client can perform
> DML
> > > >> against
> > > >> > an hbase-2 cluster.
> > > >> >
> > > >> > For the full list of ~6k issues addressed, see [2]. There are also
> > > >> > CHANGES.md and RELEASENOTES.md in the root directory of the source
> > > >> tarball.
> > > >> >
> > > >> > Please take a few minutes to verify the release and vote on
> > releasing
> > > >> it:
> > > >> >
> > > >> > [ ] +1 Release this package as Apache HBase 2.0.0
> > > >> > [ ] +0 no opinion
> > > >> > [ ] -1 Do not release this package because...
> > > >> >
> > > >> > This VOTE will run for one week and close Tuesday, April 17, 2018
> @
> > > >> 13:00
> > > >> > PST.
> > > >> >
> > > >> > Thanks to the myriad who have helped out with this release,
> > > >> > Your 2.0.0 Release Manager
> > > >> >
> > > >> > 1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
> > > >> > 2.  https://s.apache.org/zwS9
> > > >>
> > > >
> > > >
> > >
> >
>

[jira] [Reopened] (HBASE-20224) Web UI is broken in standalone mode

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi reopened HBASE-20224:
---

Reopening to push addendum 4 and 5 to branch-2.0.

> Web UI is broken in standalone mode
> ---
>
> Key: HBASE-20224
> URL: https://issues.apache.org/jira/browse/HBASE-20224
> Project: HBase
>  Issue Type: Bug
>  Components: UI, Usability
>Affects Versions: 2.0.0-beta-2
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: 
> 0001-HBASE-20224-Web-UI-is-broken-in-standalone-mode-ADDE.ADDENDUM.patch, 
> 20224-addendum.3.txt, 20224.addendum.4, 20224.addendum.5, 20224.addendum.6, 
> hbase-20224.master.001.patch, hbase-20224.master.002.patch, 
> hbase-20224.master.003.patch, hbase-20224.master.addendum.patch
>
>
> Web UI doesn't show up in standalone mode on default port. This can be seen 
> on master and branch-2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Peter Somogyi]

-1

Tests under hbase-rsgroup fail in setup phase. It is related to
HBASE-20224, some addendums were not backported to branch-2.0 which causes
the failure. I'm reopening HBASE-20224 and backport 2 missing commits.

On Fri, Apr 13, 2018 at 3:54 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> Exactly what I was looking for! Thanks Sean!
>
> 2018-04-13 9:37 GMT-04:00 Sean Busbey :
>
> > Hi JMS!
> >
> > Current flaky results for branch-2.0, generated today AFAICT:
> >
> > https://builds.apache.org/view/H-L/view/HBase/job/HBase-
> > Find-Flaky-Tests-branch2.0/lastSuccessfulBuild/artifact/
> >
> > you can look at the "dashboard.html" artifact for a human usable idea
> > of what we think is broken.
> >
> > you can fetch the excludes file to get a pattern you can pass to Maven.
> >
> >
> > On Fri, Apr 13, 2018 at 7:40 AM, Jean-Marc Spaggiari
> >  wrote:
> > > Do we have a list of tests that we know will not pass this release?
> > >
> > > I got those failures so far, but since I want to run multiple runs, I
> > want
> > > to make sure to exclude the un-stable tests.
> > >
> > > TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152
> Metrics
> > > Should be equal expected:<1> but was:<0>
> > > TestReplicationSmallTests.testDisableEnable:198 Replication wasn't
> > disabled
> > > TestReplicationSmallTests.testSimplePutDelete:168->
> TestReplicationBase.
> > runSimplePutDeleteTest:266
> > > Waited too much time for put replication
> > > TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
> > > callDurat...
> > >
> > > Thanks,
> > >
> > > JMS
> > >
> > >
> > > 2018-04-13 0:19 GMT-04:00 Yu Li :
> > >
> > >> bq. I'd imagine that if the difference were large, then yes, it should
> > >> be a blocker
> > >> -- or we as a community can decide to work on it in a follow-on
> release
> > >> making perf a priority (say, 2.1.0).
> > >> I see, thanks for the clarification boss, makes sense.
> > >>
> > >> Best Regards,
> > >> Yu
> > >>
> > >> On 13 April 2018 at 06:02, Stack  wrote:
> > >>
> > >> > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
> > >> >
> > >> > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey 
> > >> wrote:
> > >> > >
> > >> > >> no compat report in the RC directory. does that mean we won't
> have
> > one
> > >> > >> in the dist area?
> > >> > >>
> > >> > >>
> > >> > >> not a blocker; we've been inconsistent on it in prior releases,
> but
> > >> > >> the trend seemed to be towards including it.
> > >> > >>
> > >> > >>
> > >> > >
> > >> > > HBASE-18622 has current state of compatibility compare. Let me do
> a
> > new
> > >> > > run and add it to the RC dir.
> > >> > >
> > >> >
> > >> > I just added
> > >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > >> > compat-check-v1.2.6-v2.0.0.report.html
> > >> >
> > >> > Thanks,
> > >> > S
> > >> >
> > >> >
> > >> >
> > >> > > St.Ack
> > >> > >
> > >> > >
> > >> > >
> > >> > >>
> > >> > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack  wrote:
> > >> > >> > The first release candidate for Apache HBase 2.0.0 is available
> > for
> > >> > >> > downloading and testing.
> > >> > >> >
> > >> > >> > Artifacts are available here:
> > >> > >> >
> > >> > >> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > >> > >> >
> > >> > >> > Maven artifacts are available in the staging repository at:
> > >> > >> >
> > >> > >> >  https://repository.apache.org/content/repositories/
> > >> > orgapachehbase-1209
> > >> > >> >
> > >> > >> > All artifacts are signed with my signing key 8ACC93D2, which is
> > also
> > >> > >> > in the project KEYS file at
> > >> > >> >
> > >> > >> >  http://www.apache.org/dist/hbase/KEYS
> > >> > >> >
> > >> > >> > These artifacts were tagged 2.0.0RC0 at
> > >> > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
> > >> > >> >
> > >> > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase
> > 2.0.0
> > >> > >> > Reference Guide before installing or upgrading for a list of
> > >> > >> > incompatibilities, major changes, and notable new features. Be
> > aware
> > >> > >> that
> > >> > >> > according to our adopted Semantic Versioning guidelines[1],
> we've
> > >> > allow
> > >> > >> > ourselves to make breaking changes in this major version
> release.
> > >> For
> > >> > >> > example, Coprocessors will need to be recast to fit more
> > constrained
> > >> > CP
> > >> > >> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x
> > >> > without
> > >> > >> > downtime is (currently) not possible. That said, a bunch of
> > effort
> > >> has
> > >> > >> been
> > >> > >> > expended mitigating differences; a hbase-1.x client can perform
> > DML
> > >> > >> against
> > >> > >> > an hbase-2 cluster.
> > >> > >> >
> > >> > >> > For the full list of ~6k issues addressed, see [2]. There are
> > also
> > >> > >> > CHANGES.md and RELEASENOTES.md in the root 

Re: [DISCUSS] RowCounter duplication

[Peter Somogyi]

Thanks Chia-Ping Tsai and Sean Busbey for the inputs. Looks like we need to
keep both versions.

Regards,
Peter

On Wed, Apr 11, 2018 at 5:25 PM, Sean Busbey  wrote:

> So long as we're still supporting integration with the Apache Hadoop
> MapReduce project including versions that have both the old and new
> api, I think we need to support both.
>
> On Wed, Apr 11, 2018 at 7:15 AM, Peter Somogyi 
> wrote:
> > Thanks for bringing this up Chia-Ping Tsai. Yes, the question can be more
> > general whether we need to support the old API.
> >
> > On Tue, Apr 10, 2018 at 7:49 PM, Chia-Ping Tsai 
> wrote:
> >
> >> There are other tools having two versions - o.a.h.h.mapreduce and
> >> o.a.h.h.mapred
> >> It seems to me the question is "should hbase support old MR APIs ?'
> Given
> >> that hadoop 3.0 doesn't mark old MR APIs deprecated, we should keep
> them in
> >> hbase? Or we can deprecate them in hbase-2+ in order to remove them in
> the
> >> future?
> >>
> >> On 2018/04/10 16:02:07, Peter Somogyi  wrote:
> >> > Hi,
> >> >
> >> > Currently we have 2 RowCounter tools in our
> >> > repository: o.a.h.h.mapreduce.RowCounter and
> o.a.h.h.mapred.RowCounter.
> >> > None of them is marked as deprecated but mapred.RowCounter was
> deprecated
> >> > in pre-HBase 1 releases and the annotation was eventually removed
> >> > in HBASE-11178.
> >> >
> >> > Do we still want to or need to keep both versions? The mapred tool is
> not
> >> > documented in refguide and the command's usage is minimal. The
> >> > mapreduce.RowCounter tool also has more features.
> >> >
> >> > Thanks,
> >> > Peter
> >> >
> >>
>

[jira] [Created] (HBASE-20410) upgrade protoc compiler to 3.5.1-1

[Mike Drob (JIRA)]

Mike Drob created HBASE-20410:
-

 Summary: upgrade protoc compiler to 3.5.1-1
 Key: HBASE-20410
 URL: https://issues.apache.org/jira/browse/HBASE-20410
 Project: HBase
  Issue Type: Bug
  Components: build, dependencies, Protobufs
Reporter: Mike Drob
Assignee: Mike Drob


See HBASE-20356

After doing the cleanup there, I was informed that there's a 3.5.1-1 version of 
the compiler binaries that work on rhel6, so let's just go to that. Wish I knew 
about it beforehand.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Jean-Marc Spaggiari]

Exactly what I was looking for! Thanks Sean!

2018-04-13 9:37 GMT-04:00 Sean Busbey :

> Hi JMS!
>
> Current flaky results for branch-2.0, generated today AFAICT:
>
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-
> Find-Flaky-Tests-branch2.0/lastSuccessfulBuild/artifact/
>
> you can look at the "dashboard.html" artifact for a human usable idea
> of what we think is broken.
>
> you can fetch the excludes file to get a pattern you can pass to Maven.
>
>
> On Fri, Apr 13, 2018 at 7:40 AM, Jean-Marc Spaggiari
>  wrote:
> > Do we have a list of tests that we know will not pass this release?
> >
> > I got those failures so far, but since I want to run multiple runs, I
> want
> > to make sure to exclude the un-stable tests.
> >
> > TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152 Metrics
> > Should be equal expected:<1> but was:<0>
> > TestReplicationSmallTests.testDisableEnable:198 Replication wasn't
> disabled
> > TestReplicationSmallTests.testSimplePutDelete:168->TestReplicationBase.
> runSimplePutDeleteTest:266
> > Waited too much time for put replication
> > TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
> > callDurat...
> >
> > Thanks,
> >
> > JMS
> >
> >
> > 2018-04-13 0:19 GMT-04:00 Yu Li :
> >
> >> bq. I'd imagine that if the difference were large, then yes, it should
> >> be a blocker
> >> -- or we as a community can decide to work on it in a follow-on release
> >> making perf a priority (say, 2.1.0).
> >> I see, thanks for the clarification boss, makes sense.
> >>
> >> Best Regards,
> >> Yu
> >>
> >> On 13 April 2018 at 06:02, Stack  wrote:
> >>
> >> > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
> >> >
> >> > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey 
> >> wrote:
> >> > >
> >> > >> no compat report in the RC directory. does that mean we won't have
> one
> >> > >> in the dist area?
> >> > >>
> >> > >>
> >> > >> not a blocker; we've been inconsistent on it in prior releases, but
> >> > >> the trend seemed to be towards including it.
> >> > >>
> >> > >>
> >> > >
> >> > > HBASE-18622 has current state of compatibility compare. Let me do a
> new
> >> > > run and add it to the RC dir.
> >> > >
> >> >
> >> > I just added
> >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> >> > compat-check-v1.2.6-v2.0.0.report.html
> >> >
> >> > Thanks,
> >> > S
> >> >
> >> >
> >> >
> >> > > St.Ack
> >> > >
> >> > >
> >> > >
> >> > >>
> >> > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack  wrote:
> >> > >> > The first release candidate for Apache HBase 2.0.0 is available
> for
> >> > >> > downloading and testing.
> >> > >> >
> >> > >> > Artifacts are available here:
> >> > >> >
> >> > >> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> >> > >> >
> >> > >> > Maven artifacts are available in the staging repository at:
> >> > >> >
> >> > >> >  https://repository.apache.org/content/repositories/
> >> > orgapachehbase-1209
> >> > >> >
> >> > >> > All artifacts are signed with my signing key 8ACC93D2, which is
> also
> >> > >> > in the project KEYS file at
> >> > >> >
> >> > >> >  http://www.apache.org/dist/hbase/KEYS
> >> > >> >
> >> > >> > These artifacts were tagged 2.0.0RC0 at
> >> > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
> >> > >> >
> >> > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase
> 2.0.0
> >> > >> > Reference Guide before installing or upgrading for a list of
> >> > >> > incompatibilities, major changes, and notable new features. Be
> aware
> >> > >> that
> >> > >> > according to our adopted Semantic Versioning guidelines[1], we've
> >> > allow
> >> > >> > ourselves to make breaking changes in this major version release.
> >> For
> >> > >> > example, Coprocessors will need to be recast to fit more
> constrained
> >> > CP
> >> > >> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x
> >> > without
> >> > >> > downtime is (currently) not possible. That said, a bunch of
> effort
> >> has
> >> > >> been
> >> > >> > expended mitigating differences; a hbase-1.x client can perform
> DML
> >> > >> against
> >> > >> > an hbase-2 cluster.
> >> > >> >
> >> > >> > For the full list of ~6k issues addressed, see [2]. There are
> also
> >> > >> > CHANGES.md and RELEASENOTES.md in the root directory of the
> source
> >> > >> tarball.
> >> > >> >
> >> > >> > Please take a few minutes to verify the release and vote on
> >> releasing
> >> > >> it:
> >> > >> >
> >> > >> > [ ] +1 Release this package as Apache HBase 2.0.0
> >> > >> > [ ] +0 no opinion
> >> > >> > [ ] -1 Do not release this package because...
> >> > >> >
> >> > >> > This VOTE will run for one week and close Tuesday, April 17,
> 2018 @
> >> > >> 13:00
> >> > >> > PST.
> >> > >> >
> >> > >> > Thanks to the myriad who have helped out with this release,
> >> > >> > Your 2.0.0 Release Manager
> >> > >> >
> >> > >> > 

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Sean Busbey]

Hi JMS!

Current flaky results for branch-2.0, generated today AFAICT:

https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests-branch2.0/lastSuccessfulBuild/artifact/

you can look at the "dashboard.html" artifact for a human usable idea
of what we think is broken.

you can fetch the excludes file to get a pattern you can pass to Maven.


On Fri, Apr 13, 2018 at 7:40 AM, Jean-Marc Spaggiari
 wrote:
> Do we have a list of tests that we know will not pass this release?
>
> I got those failures so far, but since I want to run multiple runs, I want
> to make sure to exclude the un-stable tests.
>
> TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152 Metrics
> Should be equal expected:<1> but was:<0>
> TestReplicationSmallTests.testDisableEnable:198 Replication wasn't disabled
> TestReplicationSmallTests.testSimplePutDelete:168->TestReplicationBase.runSimplePutDeleteTest:266
> Waited too much time for put replication
> TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
> callDurat...
>
> Thanks,
>
> JMS
>
>
> 2018-04-13 0:19 GMT-04:00 Yu Li :
>
>> bq. I'd imagine that if the difference were large, then yes, it should
>> be a blocker
>> -- or we as a community can decide to work on it in a follow-on release
>> making perf a priority (say, 2.1.0).
>> I see, thanks for the clarification boss, makes sense.
>>
>> Best Regards,
>> Yu
>>
>> On 13 April 2018 at 06:02, Stack  wrote:
>>
>> > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
>> >
>> > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey 
>> wrote:
>> > >
>> > >> no compat report in the RC directory. does that mean we won't have one
>> > >> in the dist area?
>> > >>
>> > >>
>> > >> not a blocker; we've been inconsistent on it in prior releases, but
>> > >> the trend seemed to be towards including it.
>> > >>
>> > >>
>> > >
>> > > HBASE-18622 has current state of compatibility compare. Let me do a new
>> > > run and add it to the RC dir.
>> > >
>> >
>> > I just added
>> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
>> > compat-check-v1.2.6-v2.0.0.report.html
>> >
>> > Thanks,
>> > S
>> >
>> >
>> >
>> > > St.Ack
>> > >
>> > >
>> > >
>> > >>
>> > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack  wrote:
>> > >> > The first release candidate for Apache HBase 2.0.0 is available for
>> > >> > downloading and testing.
>> > >> >
>> > >> > Artifacts are available here:
>> > >> >
>> > >> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
>> > >> >
>> > >> > Maven artifacts are available in the staging repository at:
>> > >> >
>> > >> >  https://repository.apache.org/content/repositories/
>> > orgapachehbase-1209
>> > >> >
>> > >> > All artifacts are signed with my signing key 8ACC93D2, which is also
>> > >> > in the project KEYS file at
>> > >> >
>> > >> >  http://www.apache.org/dist/hbase/KEYS
>> > >> >
>> > >> > These artifacts were tagged 2.0.0RC0 at
>> > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
>> > >> >
>> > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0
>> > >> > Reference Guide before installing or upgrading for a list of
>> > >> > incompatibilities, major changes, and notable new features. Be aware
>> > >> that
>> > >> > according to our adopted Semantic Versioning guidelines[1], we've
>> > allow
>> > >> > ourselves to make breaking changes in this major version release.
>> For
>> > >> > example, Coprocessors will need to be recast to fit more constrained
>> > CP
>> > >> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x
>> > without
>> > >> > downtime is (currently) not possible. That said, a bunch of effort
>> has
>> > >> been
>> > >> > expended mitigating differences; a hbase-1.x client can perform DML
>> > >> against
>> > >> > an hbase-2 cluster.
>> > >> >
>> > >> > For the full list of ~6k issues addressed, see [2]. There are also
>> > >> > CHANGES.md and RELEASENOTES.md in the root directory of the source
>> > >> tarball.
>> > >> >
>> > >> > Please take a few minutes to verify the release and vote on
>> releasing
>> > >> it:
>> > >> >
>> > >> > [ ] +1 Release this package as Apache HBase 2.0.0
>> > >> > [ ] +0 no opinion
>> > >> > [ ] -1 Do not release this package because...
>> > >> >
>> > >> > This VOTE will run for one week and close Tuesday, April 17, 2018 @
>> > >> 13:00
>> > >> > PST.
>> > >> >
>> > >> > Thanks to the myriad who have helped out with this release,
>> > >> > Your 2.0.0 Release Manager
>> > >> >
>> > >> > 1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
>> > >> > 2.  https://s.apache.org/zwS9
>> > >>
>> > >
>> > >
>> >
>>

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Jean-Marc Spaggiari]

Do we have a list of tests that we know will not pass this release?

I got those failures so far, but since I want to run multiple runs, I want
to make sure to exclude the un-stable tests.

TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152 Metrics
Should be equal expected:<1> but was:<0>
TestReplicationSmallTests.testDisableEnable:198 Replication wasn't disabled
TestReplicationSmallTests.testSimplePutDelete:168->TestReplicationBase.runSimplePutDeleteTest:266
Waited too much time for put replication
TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
callDurat...

Thanks,

JMS


2018-04-13 0:19 GMT-04:00 Yu Li :

> bq. I'd imagine that if the difference were large, then yes, it should
> be a blocker
> -- or we as a community can decide to work on it in a follow-on release
> making perf a priority (say, 2.1.0).
> I see, thanks for the clarification boss, makes sense.
>
> Best Regards,
> Yu
>
> On 13 April 2018 at 06:02, Stack  wrote:
>
> > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
> >
> > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey 
> wrote:
> > >
> > >> no compat report in the RC directory. does that mean we won't have one
> > >> in the dist area?
> > >>
> > >>
> > >> not a blocker; we've been inconsistent on it in prior releases, but
> > >> the trend seemed to be towards including it.
> > >>
> > >>
> > >
> > > HBASE-18622 has current state of compatibility compare. Let me do a new
> > > run and add it to the RC dir.
> > >
> >
> > I just added
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > compat-check-v1.2.6-v2.0.0.report.html
> >
> > Thanks,
> > S
> >
> >
> >
> > > St.Ack
> > >
> > >
> > >
> > >>
> > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack  wrote:
> > >> > The first release candidate for Apache HBase 2.0.0 is available for
> > >> > downloading and testing.
> > >> >
> > >> > Artifacts are available here:
> > >> >
> > >> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > >> >
> > >> > Maven artifacts are available in the staging repository at:
> > >> >
> > >> >  https://repository.apache.org/content/repositories/
> > orgapachehbase-1209
> > >> >
> > >> > All artifacts are signed with my signing key 8ACC93D2, which is also
> > >> > in the project KEYS file at
> > >> >
> > >> >  http://www.apache.org/dist/hbase/KEYS
> > >> >
> > >> > These artifacts were tagged 2.0.0RC0 at
> > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
> > >> >
> > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0
> > >> > Reference Guide before installing or upgrading for a list of
> > >> > incompatibilities, major changes, and notable new features. Be aware
> > >> that
> > >> > according to our adopted Semantic Versioning guidelines[1], we've
> > allow
> > >> > ourselves to make breaking changes in this major version release.
> For
> > >> > example, Coprocessors will need to be recast to fit more constrained
> > CP
> > >> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x
> > without
> > >> > downtime is (currently) not possible. That said, a bunch of effort
> has
> > >> been
> > >> > expended mitigating differences; a hbase-1.x client can perform DML
> > >> against
> > >> > an hbase-2 cluster.
> > >> >
> > >> > For the full list of ~6k issues addressed, see [2]. There are also
> > >> > CHANGES.md and RELEASENOTES.md in the root directory of the source
> > >> tarball.
> > >> >
> > >> > Please take a few minutes to verify the release and vote on
> releasing
> > >> it:
> > >> >
> > >> > [ ] +1 Release this package as Apache HBase 2.0.0
> > >> > [ ] +0 no opinion
> > >> > [ ] -1 Do not release this package because...
> > >> >
> > >> > This VOTE will run for one week and close Tuesday, April 17, 2018 @
> > >> 13:00
> > >> > PST.
> > >> >
> > >> > Thanks to the myriad who have helped out with this release,
> > >> > Your 2.0.0 Release Manager
> > >> >
> > >> > 1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
> > >> > 2.  https://s.apache.org/zwS9
> > >>
> > >
> > >
> >
>

[jira] [Created] (HBASE-20409) Set hbase.client.meta.operation.timeout in TestClientOperationTimeout

[Peter Somogyi (JIRA)]

Peter Somogyi created HBASE-20409:
-

 Summary: Set hbase.client.meta.operation.timeout in 
TestClientOperationTimeout
 Key: HBASE-20409
 URL: https://issues.apache.org/jira/browse/HBASE-20409
 Project: HBase
  Issue Type: Improvement
  Components: test
Affects Versions: 3.0.0, 2.1.0, 2.0.0
Reporter: Peter Somogyi
Assignee: Peter Somogyi


In TestClientOperationTimeout the hbase.client.meta.operation.timeout property 
is not, so default value is used which is 120ms. The test finishes earlier 
if we set the timeout to match with hbase.client.meta.operation.timeout.

Since the first call will go to META table where the default timeout is used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20408) Plug-gable retry policy in all admin API's

[Divesh Jain (JIRA)]

Divesh Jain created HBASE-20408:
---

 Summary: Plug-gable retry policy in all admin API's
 Key: HBASE-20408
 URL: https://issues.apache.org/jira/browse/HBASE-20408
 Project: HBase
  Issue Type: New Feature
Reporter: Divesh Jain


All admin API's that are retry able should support custom retry policy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-20400) Make `MAX_WAIT` and `waitIfNotFinished` in CleanerContext configurable

[Sean Busbey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey resolved HBASE-20400.
-
Resolution: Duplicate

> Make `MAX_WAIT` and `waitIfNotFinished` in CleanerContext configurable
> --
>
> Key: HBASE-20400
> URL: https://issues.apache.org/jira/browse/HBASE-20400
> Project: HBase
>  Issue Type: Improvement
>  Components: master, Performance
>Affects Versions: 3.0.0, 1.5.0, 2.0.0-beta-1, 1.4.4, 2.0.0
>Reporter: Tak Lon (Stephen) Wu
>Priority: Minor
>
> When backporting HBASE-18309 in HBASE-20352, the deleteFiles calls
> CleanerContext.java#getResult with a waitIfNotFinished timeout to wait for 
> notification (notify) from the fs.delete file thread. there might be two 
> situation need to tune the MAX_WAIT in CleanerContext or make a configuration 
> property for waitIfNotFinished when LogClearner call getResult. 
> 1. fs.delete never complete (strange but possible), then we need to wait for 
> a max of 60 seconds. here, 60 seconds might be too long
> 2. getResult is waiting in the period of 500 milliseconds, but the fs.delete 
> has completed and setFromClear is set but yet notify(). one might want to 
> tune this 500 milliseconds to 200 or less .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20407) Retry HBase admin API if master failover is in progress

[Divesh Jain (JIRA)]

Divesh Jain created HBASE-20407:
---

 Summary: Retry HBase admin API if master failover is in progress
 Key: HBASE-20407
 URL: https://issues.apache.org/jira/browse/HBASE-20407
 Project: HBase
  Issue Type: Improvement
  Components: Admin
Reporter: Divesh Jain


When a master switch over is in progress and an admin API is called, perform a 
retry operation before throwing an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)