[jira] [Created] (HBASE-21593) closing flags show be set false in HRegion

[xiaolerzheng (JIRA)]

xiaolerzheng created HBASE-21593:


 Summary: closing flags show be set false in HRegion
 Key: HBASE-21593
 URL: https://issues.apache.org/jira/browse/HBASE-21593
 Project: HBase
  Issue Type: Bug
Reporter: xiaolerzheng


in HRegion.java

 

 

1429 // block waiting for the lock for closing
1430 lock.writeLock().lock();
1431 this.closing.set(true);
1432 status.setStatus("Disabling writes for close");

 



 

 

1557 } finally {

       {color:#FF}  //should here add {color}

    {color:#FF}    this.closing.set(false); {color}
1558  lock.writeLock().unlock();
1559 }



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

[jira] [Created] (HBASE-21592) quota.addGetResult(r) throw NPE

[xuqinya (JIRA)]

xuqinya created HBASE-21592:
---

 Summary: quota.addGetResult(r)  throw  NPE
 Key: HBASE-21592
 URL: https://issues.apache.org/jira/browse/HBASE-21592
 Project: HBase
  Issue Type: Bug
Reporter: xuqinya


Setting the RPC quota, table.exists(Get) cause quota.addGetResult(r)  throw  
NPE.

 

set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT => '1000req/sec'

Connection conn = ConnectionFactory.createConnection(config);
Table htable = conn.getTable(TableName.valueOf("ns1:t1"));
boolean exists = htable.exists(new Get(Bytes.toBytes("123")));

log:

java.io.IOException: java.io.IOException
 at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2183)
 at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
 at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
 at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
 at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
 at 
org.apache.hadoop.hbase.quotas.QuotaUtil.calculateResultSize(QuotaUtil.java:282)
 at 
org.apache.hadoop.hbase.quotas.DefaultOperationQuota.addGetResult(DefaultOperationQuota.java:99)
 at 
org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:1907)
 at 
org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32381)
 at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
 ... 4 more



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

Re: [VOTE] First release candidate for HBase 2.0.4 is available hbase

[Allan Yang]

This UT is written by me. @Andrew, can you upload the output? I can't
reproduce it form my laptop. I'm also  using Mac OS High
Sierra, with jdk1.8.0_19.
Sorry for the inconvenience.
Best Regards
Allan Yang


Andrew Purtell  于2018年12月12日周三 上午2:56写道：

> TestCleanupMetaWAL#testCleanupMetaWAL fails for me consistently, both for
> 2.0.4 and 2.1.2 RCs. Mac OS High Sierra, OpenJDK Runtime Environment (Zulu
> 8.30.0.2-macosx) (build 1.8.0_172-b01)
> java.lang.AssertionError: Waiting timed out after [10,000] msec
> at
>
> org.apache.hadoop.hbase.regionserver.TestCleanupMetaWAL.testCleanupMetaWAL(TestCleanupMetaWAL.java:70)
>
> Output of failed test run is available upon request if you can't reproduce.
>
>
> On Fri, Dec 7, 2018 at 11:21 AM Stack  wrote:
>
> > The first release candidate for HBase 2.0.4 is available for download:
> >
> >  *https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/
> > *
> >
> > Maven artifacts are also available in a staging repository at:
> >
> >  https://repository.apache.org/content/repositories/orgapachehbase-1241
> >
> > Artifacts are signed with my key (DB9D313DA7874F29) published in our
> > KEYS file at http://www.apache.org/dist/hbase/KEYS
> >
> > The RC corresponds to the signed tag 2.0.4RC0, which currently points
> > to commit
> >
> >   9097821560f630dff0fb9df4b0c589ad2acb8016
> >
> > HBase 2.0.4 is the fourth maintenance release in the HBase 2.0 line,
> > continuing on the theme of bringing a stable, reliable database to
> > the Hadoop and NoSQL communities. It fixes a critical issue found
> > in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.0.4
> > includes ~12 bug and improvement fixes done since the 2.0.3,
> > two weeks ago.
> >
> > The detailed source and binary compatibility report vs 2.0.3 has been
> > published for your review, at:
> >
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/compatibiilty_report_2.0.3vs2.04.html
> >
> > The report shows no incompatibilities.
> >
> > The full list of fixes included in this release is available in
> > the CHANGES.md that ships as part of the release also available
> > here:
> >
> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/CHANGES.md
> >
> > The RELEASENOTES.md are here:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/RELEASENOTES.md
> >
> > Please try out this candidate and vote +1/-1 on whether we should
> > release these artifacts as HBase 2.0.4.
> >
> > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > I would like to close it on Tuesday, December 11th, 2018.
> >
> > Thanks,
> > S
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

[jira] [Reopened] (HBASE-21575) memstore above high watermark message is logged too much

[Peter Somogyi (JIRA)]

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

Peter Somogyi reopened HBASE-21575:
---

Reopening to fix commit

> memstore above high watermark message is logged too much
> 
>
> Key: HBASE-21575
> URL: https://issues.apache.org/jira/browse/HBASE-21575
> Project: HBase
>  Issue Type: Bug
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21575.01.patch, HBASE-21575.patch
>
>
> 100s of Mb of logs like this, in a tight loop:
> {noformat}
> 2018-12-08 10:27:00,462 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3646ms
> 2018-12-08 10:27:00,463 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3647ms
> 2018-12-08 10:27:00,463 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3647ms
> 2018-12-08 10:27:00,464 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3648ms
> 2018-12-08 10:27:00,464 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3648ms
> 2018-12-08 10:27:00,465 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3649ms
> 2018-12-08 10:27:00,465 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3649ms
> 2018-12-08 10:27:00,466 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3650ms
> 2018-12-08 10:27:00,466 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3650ms
> 2018-12-08 10:27:00,467 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3651ms
> 2018-12-08 10:27:00,469 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3653ms
> 2018-12-08 10:27:00,470 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3654ms
> 2018-12-08 10:27:00,470 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3654ms
> 2018-12-08 10:27:00,471 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3655ms
> 2018-12-08 10:27:00,471 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3655ms
> 2018-12-08 10:27:00,472 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3656ms
> 2018-12-08 10:27:00,472 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3656ms
> 2018-12-08 10:27:00,473 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3657ms
> 2018-12-08 10:27:00,474 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3658ms
> 2018-12-08 10:27:00,475 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3659ms
> 2018-12-08 10:27:00,476 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3660ms
> 2018-12-08 10:27:00,476 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3660ms
> 2018-12-08 10:27:00,477 WARN  
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=2,port=17020] 
> regionserver.MemStoreFlusher: Memstore is above high water mark and block 
> 3661ms
> 2018-12-08 10:27:00,477 WARN  
> 

[jira] [Created] (HBASE-21591) Support ability to have host based permissions

[Clay B. (JIRA)]

Clay B. created HBASE-21591:
---

 Summary: Support ability to have host based permissions
 Key: HBASE-21591
 URL: https://issues.apache.org/jira/browse/HBASE-21591
 Project: HBase
  Issue Type: Improvement
  Components: security
Reporter: Clay B.
Assignee: Clay B.


Today, one can put in an ACL rule where a user is not permitted to read data 
but can insert data (e.g. {{grant 'user', 'table', 'W'}}). However, one can not 
implement HBase as a "drop-box" for data where by in a secure network, one can 
read and write data but outside that secure network one can only write data; 
and I do not believe this is possible with custom access controllers, unless 
one "wraps" HBase; e.g. with the HBase REST server.

I have been pushing for this model (e.g. [Of Data Dropboxes and Data 
Gloveboxes|https://thestrangeloop.com/2018/of-data-dropboxes-and-data-gloveboxes.html]
 or 
[slides|http://clayb.net/presentations/Of%20Data%20Dropboxes%20and%20Data%20Gloveboxes.pdf])
 in a number of technologies for some data compartmentalization initiatives.

I propose passing the requester's host information through the HBase 
authentication stack so that the ACL model in HBase can work akin to the SQL 
semantics of {{user@host}} or {{user@}}.The expected impact would be 
to HBase private interfaces only, so far in POC'ing it seems the following 
would be impacted:

Access Control Classes/ACL Table Management:
* AccessControlUtil
* UserPermission
* AccessChecker
* AccessControlFilter
* AccessController
* AuthResult
* TableAuthManager
* AccessControl.proto

Co-Processor APIs for Checking Authentication:
* CoprocessorHost
* ObserverContext
* ObserverContextImpl
* RSRpcServices
* RSGroupAdminEndpoint



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

[jira] [Created] (HBASE-21590) Optimize trySkipToNextColumn in StoreScanner a bit

[Lars Hofhansl (JIRA)]

Lars Hofhansl created HBASE-21590:
-

 Summary: Optimize trySkipToNextColumn in StoreScanner a bit
 Key: HBASE-21590
 URL: https://issues.apache.org/jira/browse/HBASE-21590
 Project: HBase
  Issue Type: Task
Reporter: Lars Hofhansl


See latest comment on HBASE-17958



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

[jira] [Resolved] (HBASE-19034) Implement "optimize SEEK to SKIP" in storefile scanner

[Lars Hofhansl (JIRA)]

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

Lars Hofhansl resolved HBASE-19034.
---
Resolution: Won't Fix

Closing as "Won't Fix" as it turns out that the doing this optimization at the 
StoreFile (or HFile) Scanner level misses the most important opportunity for 
optimization - it's too far down the stack.

> Implement "optimize SEEK to SKIP" in storefile scanner
> --
>
> Key: HBASE-19034
> URL: https://issues.apache.org/jira/browse/HBASE-19034
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Guanghao Zhang
>Priority: Major
>
> {code}
>   protected boolean trySkipToNextRow(Cell cell) throws IOException {
> Cell nextCell = null;
> do { 
>   Cell nextIndexedKey = getNextIndexedKey();
>   if (nextIndexedKey != null && nextIndexedKey != 
> KeyValueScanner.NO_NEXT_INDEXED_KEY
>   && matcher.compareKeyForNextRow(nextIndexedKey, cell) >= 0) { 
> this.heap.next();
> ++kvsScanned;
>   } else {
> return false;
>   }
> } while ((nextCell = this.heap.peek()) != null && 
> CellUtil.matchingRows(cell, nextCell));
> return true;
>   }
> {code}
> When SQM return a SEEK_NEXT_ROW, the store scanner will seek to the cell from 
> next row. HBASE-13109 optimized the SEEK to SKIP when we can read the cell in 
> current loaded block. So it will skip by call heap.next to the cell from next 
> row. But the problem is it compare too many times with the nextIndexedKey in 
> the while loop. We plan move the compare outside the loop to reduce compare 
> times. One problem is the nextIndexedKey maybe changed when call heap.peek, 
> because the current storefile scanner was changed. So my proposal is to move 
> the "optimize SEEK to SKIP" to storefile scanner. When we call seek for 
> storefile scanner, it may real seek or implement seek by several times skip.
> Any suggestions are welcomed. Thanks.



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

[CANCELLED][VOTE] First release candidate for HBase 2.0.4 is available hbase

[Stack]

Because of HBASE-21589 (Thanks Andrew P).
S

On Fri, Dec 7, 2018 at 11:21 AM Stack  wrote:

> The first release candidate for HBase 2.0.4 is available for download:
>
>  *https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/
> *
>
> Maven artifacts are also available in a staging repository at:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1241
>
> Artifacts are signed with my key (DB9D313DA7874F29) published in our
> KEYS file at http://www.apache.org/dist/hbase/KEYS
>
> The RC corresponds to the signed tag 2.0.4RC0, which currently points
> to commit
>
>   9097821560f630dff0fb9df4b0c589ad2acb8016
>
> HBase 2.0.4 is the fourth maintenance release in the HBase 2.0 line,
> continuing on the theme of bringing a stable, reliable database to
> the Hadoop and NoSQL communities. It fixes a critical issue found
> in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.0.4
> includes ~12 bug and improvement fixes done since the 2.0.3,
> two weeks ago.
>
> The detailed source and binary compatibility report vs 2.0.3 has been
> published for your review, at:
>
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/compatibiilty_report_2.0.3vs2.04.html
>
> The report shows no incompatibilities.
>
> The full list of fixes included in this release is available in
> the CHANGES.md that ships as part of the release also available
> here:
>
>  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/CHANGES.md
>
> The RELEASENOTES.md are here:
>
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC0/RELEASENOTES.md
>
> Please try out this candidate and vote +1/-1 on whether we should
> release these artifacts as HBase 2.0.4.
>
> The VOTE will remain open for at least 72 hours. Given sufficient votes
> I would like to close it on Tuesday, December 11th, 2018.
>
> Thanks,
> S
>

[CANCELLED][VOTE] First release candidate for HBase 2.1.2 is available for download

[Stack]

Because of HBASE-21589.
S

On Fri, Dec 7, 2018 at 3:14 PM Stack  wrote:

> The first release candidate for HBase 2.1.2 is available for download:
>
> * https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/
> *
>
> Maven artifacts are also available in a staging repository at:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1242
>
> Artifacts are signed with my key (DB9D313DA7874F29) published in our
> KEYS file at http://www.apache.org/dist/hbase/KEYS
>
> The RC corresponds to the signed tag 2.0.4RC0, which currently points
> to commit
>
>   434bd0cd91d08353a8e7207ced530df3b3b1af76
>
> HBase 2.1.2 is the third maintenance release in the HBase 2.0 line,
> continuing on the theme of bringing a stable, reliable database to
> the Hadoop and NoSQL communities. It fixes a critical issue found
> in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.1.2
> includes ~46 bug and improvement fixes done since the 2.1.1,
> ~ six weeks ago.
>
> The detailed source and binary compatibility report vs 2.1.1 has been
> published for your review, at:
>
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/compatibility_report_2.1.1vs2.1.2.html
>
> The report shows no incompatibilities.
>
> The full list of fixes included in this release is available in
> the CHANGES.md that ships as part of the release also available
> here:
>
>  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/CHANGES.md
>
> The RELEASENOTES.md are here:
>
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/RELEASENOTES.md
>
> Please try out this candidate and vote +1/-1 on whether we should
> release these artifacts as HBase 2.1.2.
>
> The VOTE will remain open for at least 72 hours. Given sufficient votes
> I would like to close it on Tuesday, December 11th, 2018.
>
> Thanks,
> S
> ReplyForward
>

[jira] [Created] (HBASE-21589) TestCleanupMetaWAL fails

[stack (JIRA)]

stack created HBASE-21589:
-

 Summary: TestCleanupMetaWAL fails
 Key: HBASE-21589
 URL: https://issues.apache.org/jira/browse/HBASE-21589
 Project: HBase
  Issue Type: Bug
Reporter: stack


This test fails near all-the-time. Sunk two RCs. Fix. Made it a blocker.



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

Re: [VOTE] First release candidate for HBase 2.1.2 is available for download

[Stack]

Looked at this again. It is a bit wonky. Using jdk10 (by mistake), the test
was passing for me. Changing to use jdk8, it fails all the time. Let me
just sink these two RCs and fix this test: HBASE-21589.

Thanks to you all for trying it.

S

On Tue, Dec 11, 2018 at 12:52 PM Stack  wrote:

> Thanks Andrew. Yeah, fails for me too. Was looking here where hbase 2.1
> looks really good:
> https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-2.1/
> ... but its factoring in an exclude flakey list that includes this failing
> test. Odd was that the failing test is not in the flakey list here:
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/job/branch-2.1/lastSuccessfulBuild/artifact/dashboard.html
>
> S
>
> On Tue, Dec 11, 2018 at 10:55 AM Andrew Purtell 
> wrote:
>
>> TestCleanupMetaWAL#testCleanupMetaWAL fails for me consistently. Mac OS
>> High Sierra, OpenJDK Runtime Environment (Zulu 8.30.0.2-macosx) (build
>> 1.8.0_172-b01)
>> java.lang.AssertionError: Waiting timed out after [10,000] msec
>> at
>>
>> org.apache.hadoop.hbase.regionserver.TestCleanupMetaWAL.testCleanupMetaWAL(TestCleanupMetaWAL.java:70)
>>
>> Output of failed test run is available upon request if you can't
>> reproduce.
>>
>>
>> On Fri, Dec 7, 2018 at 3:14 PM Stack  wrote:
>>
>> > The first release candidate for HBase 2.1.2 is available for download:
>> >
>> > * https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/
>> > *
>> >
>> > Maven artifacts are also available in a staging repository at:
>> >
>> >  https://repository.apache.org/content/repositories/orgapachehbase-1242
>> >
>> > Artifacts are signed with my key (DB9D313DA7874F29) published in our
>> > KEYS file at http://www.apache.org/dist/hbase/KEYS
>> >
>> > The RC corresponds to the signed tag 2.0.4RC0, which currently points
>> > to commit
>> >
>> >   434bd0cd91d08353a8e7207ced530df3b3b1af76
>> >
>> > HBase 2.1.2 is the third maintenance release in the HBase 2.0 line,
>> > continuing on the theme of bringing a stable, reliable database to
>> > the Hadoop and NoSQL communities. It fixes a critical issue found
>> > in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.1.2
>> > includes ~46 bug and improvement fixes done since the 2.1.1,
>> > ~ six weeks ago.
>> >
>> > The detailed source and binary compatibility report vs 2.1.1 has been
>> > published for your review, at:
>> >
>> >
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/compatibility_report_2.1.1vs2.1.2.html
>> >
>> > The report shows no incompatibilities.
>> >
>> > The full list of fixes included in this release is available in
>> > the CHANGES.md that ships as part of the release also available
>> > here:
>> >
>> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/CHANGES.md
>> >
>> > The RELEASENOTES.md are here:
>> >
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/RELEASENOTES.md
>> >
>> > Please try out this candidate and vote +1/-1 on whether we should
>> > release these artifacts as HBase 2.1.2.
>> >
>> > The VOTE will remain open for at least 72 hours. Given sufficient votes
>> > I would like to close it on Tuesday, December 11th, 2018.
>> >
>> > Thanks,
>> > S
>> > ReplyForward
>> >
>>
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>- A23, Crosstalk
>>
>

Re: [VOTE] First release candidate for HBase 2.1.2 is available for download

[Sakthi Vel]

(+1 Non-Binding)

   1. Checksums and signatures(both src and bin): OK
   2. Rat Check: OK
   3. Built from source: OK
   4. Unit Tests: OK (Passed in the second attempt)
   5. Basic Shell commands: OK
   6. Web UI: OK
   7. LTT with 1M rows: OK

-Sakthi

On Tue, Dec 11, 2018 at 12:53 PM Stack  wrote:

> Thanks Andrew. Yeah, fails for me too. Was looking here where hbase 2.1
> looks really good:
>
> https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-2.1/
> ... but its factoring in an exclude flakey list that includes this failing
> test. Odd was that the failing test is not in the flakey list here:
>
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/job/branch-2.1/lastSuccessfulBuild/artifact/dashboard.html
>
> S
>
> On Tue, Dec 11, 2018 at 10:55 AM Andrew Purtell 
> wrote:
>
> > TestCleanupMetaWAL#testCleanupMetaWAL fails for me consistently. Mac OS
> > High Sierra, OpenJDK Runtime Environment (Zulu 8.30.0.2-macosx) (build
> > 1.8.0_172-b01)
> > java.lang.AssertionError: Waiting timed out after [10,000] msec
> > at
> >
> >
> org.apache.hadoop.hbase.regionserver.TestCleanupMetaWAL.testCleanupMetaWAL(TestCleanupMetaWAL.java:70)
> >
> > Output of failed test run is available upon request if you can't
> reproduce.
> >
> >
> > On Fri, Dec 7, 2018 at 3:14 PM Stack  wrote:
> >
> > > The first release candidate for HBase 2.1.2 is available for download:
> > >
> > > * https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/
> > > *
> > >
> > > Maven artifacts are also available in a staging repository at:
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1242
> > >
> > > Artifacts are signed with my key (DB9D313DA7874F29) published in our
> > > KEYS file at http://www.apache.org/dist/hbase/KEYS
> > >
> > > The RC corresponds to the signed tag 2.0.4RC0, which currently points
> > > to commit
> > >
> > >   434bd0cd91d08353a8e7207ced530df3b3b1af76
> > >
> > > HBase 2.1.2 is the third maintenance release in the HBase 2.0 line,
> > > continuing on the theme of bringing a stable, reliable database to
> > > the Hadoop and NoSQL communities. It fixes a critical issue found
> > > in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.1.2
> > > includes ~46 bug and improvement fixes done since the 2.1.1,
> > > ~ six weeks ago.
> > >
> > > The detailed source and binary compatibility report vs 2.1.1 has been
> > > published for your review, at:
> > >
> > >
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/compatibility_report_2.1.1vs2.1.2.html
> > >
> > > The report shows no incompatibilities.
> > >
> > > The full list of fixes included in this release is available in
> > > the CHANGES.md that ships as part of the release also available
> > > here:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/CHANGES.md
> > >
> > > The RELEASENOTES.md are here:
> > >
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC0/RELEASENOTES.md
> > >
> > > Please try out this candidate and vote +1/-1 on whether we should
> > > release these artifacts as HBase 2.1.2.
> > >
> > > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > > I would like to close it on Tuesday, December 11th, 2018.
> > >
> > > Thanks,
> > > S
> > > ReplyForward
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>

[jira] [Created] (HBASE-21588) Procedure v2 wal splitting implementation

[Jingyun Tian (JIRA)]

Jingyun Tian created HBASE-21588:


 Summary: Procedure v2 wal splitting implementation
 Key: HBASE-21588
 URL: https://issues.apache.org/jira/browse/HBASE-21588
 Project: HBase
  Issue Type: Sub-task
Reporter: Jingyun Tian
Assignee: Jingyun Tian


create a sub task to submit the implementation of procedure v2 wal splitting



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