[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory
[ https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769042#comment-16769042 ] ramkrishna.s.vasudevan commented on HBASE-21874: the patch that removes the code where the Byte buffer size was configurable. That was distracting from the actual change. [~jdcryans] - Pls share your comments/feedback. > Bucket cache on Persistent memory > - > > Key: HBASE-21874 > URL: https://issues.apache.org/jira/browse/HBASE-21874 > Project: HBase > Issue Type: New Feature > Components: BucketCache >Affects Versions: 3.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21874.patch, HBASE-21874.patch, > HBASE-21874_V2.patch, Pmem_BC.png > > > Non volatile persistent memory devices are byte addressable like DRAM (for > eg. Intel DCPMM). Bucket cache implementation can take advantage of this new > memory type and can make use of the existing offheap data structures to serve > data directly from this memory area without having to bring the data to > onheap. > The patch is a new IOEngine implementation that works with the persistent > memory. > Note : Here we don't make use of the persistence nature of the device and > just make use of the big memory it provides. > Performance numbers to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21898) Release 1.2.11
[ https://issues.apache.org/jira/browse/HBASE-21898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769038#comment-16769038 ] Hudson commented on HBASE-21898: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1207 (See [https://builds.apache.org/job/HBase-1.2-IT/1207/]) HBASE-21898 update version for 1.2.11 RCs (busbey: [https://github.com/apache/hbase/commit/4b26c4a78d0541b0338e999a39f91bfcea9d637e]) * (edit) hbase-assembly/pom.xml * (edit) hbase-shaded/hbase-shaded-server/pom.xml * (edit) hbase-prefix-tree/pom.xml * (edit) hbase-rest/pom.xml * (edit) hbase-shaded/pom.xml * (edit) hbase-common/pom.xml * (edit) hbase-external-blockcache/pom.xml * (edit) hbase-client/pom.xml * (edit) hbase-checkstyle/pom.xml * (edit) hbase-server/pom.xml * (edit) hbase-shaded/hbase-shaded-check-invariants/pom.xml * (edit) hbase-shaded/hbase-shaded-client/pom.xml * (edit) pom.xml * (edit) hbase-resource-bundle/pom.xml * (edit) hbase-thrift/pom.xml * (edit) hbase-annotations/pom.xml * (edit) hbase-examples/pom.xml * (edit) hbase-procedure/pom.xml * (edit) hbase-hadoop2-compat/pom.xml * (edit) hbase-it/pom.xml * (edit) hbase-protocol/pom.xml * (edit) hbase-hadoop-compat/pom.xml * (edit) hbase-shell/pom.xml * (edit) hbase-testing-util/pom.xml HBASE-21898 update CHANGES.txt for 1.2.11 RC0 (busbey: [https://github.com/apache/hbase/commit/ca53d58f5b7abde0c189c9f78baf4246bddffac3]) * (edit) CHANGES.txt > Release 1.2.11 > -- > > Key: HBASE-21898 > URL: https://issues.apache.org/jira/browse/HBASE-21898 > Project: HBase > Issue Type: Task > Components: community >Affects Versions: 1.2.11 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Fix For: 1.2.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21874) Bucket cache on Persistent memory
[ https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-21874: --- Attachment: HBASE-21874_V2.patch > Bucket cache on Persistent memory > - > > Key: HBASE-21874 > URL: https://issues.apache.org/jira/browse/HBASE-21874 > Project: HBase > Issue Type: New Feature > Components: BucketCache >Affects Versions: 3.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21874.patch, HBASE-21874.patch, > HBASE-21874_V2.patch, Pmem_BC.png > > > Non volatile persistent memory devices are byte addressable like DRAM (for > eg. Intel DCPMM). Bucket cache implementation can take advantage of this new > memory type and can make use of the existing offheap data structures to serve > data directly from this memory area without having to bring the data to > onheap. > The patch is a new IOEngine implementation that works with the persistent > memory. > Note : Here we don't make use of the persistence nature of the device and > just make use of the big memory it provides. > Performance numbers to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection
[ https://issues.apache.org/jira/browse/HBASE-21717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769033#comment-16769033 ] Duo Zhang commented on HBASE-21717: --- OK, found a bunch of bugs in the async client implementation. Let me fix them first... > Implement Connection based on AsyncConnection > - > > Key: HBASE-21717 > URL: https://issues.apache.org/jira/browse/HBASE-21717 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21717-HBASE-21512-v1.patch, > HBASE-21717-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21910) The nonce implementation is wrong for AsyncTable
Duo Zhang created HBASE-21910: - Summary: The nonce implementation is wrong for AsyncTable Key: HBASE-21910 URL: https://issues.apache.org/jira/browse/HBASE-21910 Project: HBase Issue Type: Bug Components: asyncclient, Client Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4 We recreate the nonce every time when retry, which is not correct. And it is strange that we even do not have a UT for this... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21909) Validate the put instance before executing in AsyncTable.put method
Duo Zhang created HBASE-21909: - Summary: Validate the put instance before executing in AsyncTable.put method Key: HBASE-21909 URL: https://issues.apache.org/jira/browse/HBASE-21909 Project: HBase Issue Type: Sub-task Components: asyncclient, Client Reporter: Duo Zhang Fix For: 3.0.0, 2.2.0, 2.3.0 Align with the sync client implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21908) Remove Scan.getScanMetrics
Duo Zhang created HBASE-21908: - Summary: Remove Scan.getScanMetrics Key: HBASE-21908 URL: https://issues.apache.org/jira/browse/HBASE-21908 Project: HBase Issue Type: Task Components: Client, scan Reporter: Duo Zhang Fix For: 3.0.0 It has been deprecated in 2.x, so remove it from 3.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21907) Should set priority for rpc request
Duo Zhang created HBASE-21907: - Summary: Should set priority for rpc request Key: HBASE-21907 URL: https://issues.apache.org/jira/browse/HBASE-21907 Project: HBase Issue Type: Sub-task Components: asyncclient, Client Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0, 2.2.0, 2.3.0 Now in async client we just ignored the priority for RpcController. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20993) [Auth] IPC client fallback to simple auth allowed doesn't work
[
https://issues.apache.org/jira/browse/HBASE-20993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769012#comment-16769012
]
Reid Chan commented on HBASE-20993:
---
Uploaded v11 patch passed NettyRpcClient on local.
Expecting QA result.
> [Auth] IPC client fallback to simple auth allowed doesn't work
> --
>
> Key: HBASE-20993
> URL: https://issues.apache.org/jira/browse/HBASE-20993
> Project: HBase
> Issue Type: Bug
> Components: Client, IPC/RPC, security
>Affects Versions: 1.2.6, 1.3.2, 1.2.7, 1.4.7
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Critical
> Fix For: 1.5.1
>
> Attachments: HBASE-20993.001.patch,
> HBASE-20993.003.branch-1.flowchart.png, HBASE-20993.branch-1.002.patch,
> HBASE-20993.branch-1.003.patch, HBASE-20993.branch-1.004.patch,
> HBASE-20993.branch-1.005.patch, HBASE-20993.branch-1.006.patch,
> HBASE-20993.branch-1.007.patch, HBASE-20993.branch-1.008.patch,
> HBASE-20993.branch-1.009.patch, HBASE-20993.branch-1.009.patch,
> HBASE-20993.branch-1.010.patch, HBASE-20993.branch-1.011.patch,
> HBASE-20993.branch-1.2.001.patch, HBASE-20993.branch-1.wip.002.patch,
> HBASE-20993.branch-1.wip.patch, yetus-local-testpatch-output-009.txt
>
>
> It is easily reproducible.
> client's hbase-site.xml: hadoop.security.authentication:kerberos,
> hbase.security.authentication:kerberos,
> hbase.ipc.client.fallback-to-simple-auth-allowed:true, keytab and principal
> are right set
> A simple auth hbase cluster, a kerberized hbase client application.
> application trying to r/w/c/d table will have following exception:
> {code}
> javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Failed to find
> any Kerberos tgt)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:617)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$700(RpcClientImpl.java:162)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:740)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:740)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:906)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:873)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1241)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:227)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:336)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$BlockingStub.isMasterRunning(MasterProtos.java:58383)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.isMasterRunning(ConnectionManager.java:1592)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStubNoRetries(ConnectionManager.java:1530)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStub(ConnectionManager.java:1552)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.makeStub(ConnectionManager.java:1581)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.getKeepAliveMasterService(ConnectionManager.java:1738)
> at
> org.apache.hadoop.hbase.client.MasterCallable.prepare(MasterCallable.java:38)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:134)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4297)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4289)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsyncV2(HBaseAdmin.java:753)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:674)
> at
> org.apache.hadoop.hbase.client.HBase
[jira] [Updated] (HBASE-20993) [Auth] IPC client fallback to simple auth allowed doesn't work
[
https://issues.apache.org/jira/browse/HBASE-20993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-20993:
--
Attachment: HBASE-20993.branch-1.011.patch
> [Auth] IPC client fallback to simple auth allowed doesn't work
> --
>
> Key: HBASE-20993
> URL: https://issues.apache.org/jira/browse/HBASE-20993
> Project: HBase
> Issue Type: Bug
> Components: Client, IPC/RPC, security
>Affects Versions: 1.2.6, 1.3.2, 1.2.7, 1.4.7
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Critical
> Fix For: 1.5.1
>
> Attachments: HBASE-20993.001.patch,
> HBASE-20993.003.branch-1.flowchart.png, HBASE-20993.branch-1.002.patch,
> HBASE-20993.branch-1.003.patch, HBASE-20993.branch-1.004.patch,
> HBASE-20993.branch-1.005.patch, HBASE-20993.branch-1.006.patch,
> HBASE-20993.branch-1.007.patch, HBASE-20993.branch-1.008.patch,
> HBASE-20993.branch-1.009.patch, HBASE-20993.branch-1.009.patch,
> HBASE-20993.branch-1.010.patch, HBASE-20993.branch-1.011.patch,
> HBASE-20993.branch-1.2.001.patch, HBASE-20993.branch-1.wip.002.patch,
> HBASE-20993.branch-1.wip.patch, yetus-local-testpatch-output-009.txt
>
>
> It is easily reproducible.
> client's hbase-site.xml: hadoop.security.authentication:kerberos,
> hbase.security.authentication:kerberos,
> hbase.ipc.client.fallback-to-simple-auth-allowed:true, keytab and principal
> are right set
> A simple auth hbase cluster, a kerberized hbase client application.
> application trying to r/w/c/d table will have following exception:
> {code}
> javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Failed to find
> any Kerberos tgt)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:617)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$700(RpcClientImpl.java:162)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:740)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:740)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:906)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:873)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1241)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:227)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:336)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$BlockingStub.isMasterRunning(MasterProtos.java:58383)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.isMasterRunning(ConnectionManager.java:1592)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStubNoRetries(ConnectionManager.java:1530)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStub(ConnectionManager.java:1552)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.makeStub(ConnectionManager.java:1581)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.getKeepAliveMasterService(ConnectionManager.java:1738)
> at
> org.apache.hadoop.hbase.client.MasterCallable.prepare(MasterCallable.java:38)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:134)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4297)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4289)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsyncV2(HBaseAdmin.java:753)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:674)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:607)
> at
> org.playground.hbase.Kerberize
[jira] [Commented] (HBASE-21901) update branch-1.2 ref guide for 1.2.11 release
[
https://issues.apache.org/jira/browse/HBASE-21901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768995#comment-16768995
]
Hudson commented on HBASE-21901:
Results for branch branch-1.2
[build #663 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663//JDK7_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> update branch-1.2 ref guide for 1.2.11 release
> --
>
> Key: HBASE-21901
> URL: https://issues.apache.org/jira/browse/HBASE-21901
> Project: HBase
> Issue Type: Task
> Components: documentation
>Affects Versions: 1.2.11
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 1.2.11
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21898) Release 1.2.11
[
https://issues.apache.org/jira/browse/HBASE-21898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768996#comment-16768996
]
Hudson commented on HBASE-21898:
Results for branch branch-1.2
[build #663 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663//JDK7_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/663//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Release 1.2.11
> --
>
> Key: HBASE-21898
> URL: https://issues.apache.org/jira/browse/HBASE-21898
> Project: HBase
> Issue Type: Task
> Components: community
>Affects Versions: 1.2.11
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 1.2.11
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1
[
https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768997#comment-16768997
]
Hadoop QA commented on HBASE-21906:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-2.1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
5s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
49s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
48s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
0s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 16s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}127m 30s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 29s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.regionserver.TestOpenSeqNumUnexpectedIncrease |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-21906 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12958814/HBASE-21906-branch-2.1.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux fa8957086d8a 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.1 / c32f4b0021 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/15984/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/15984/testReport/ |
| Max. process+thread count | 5136 (vs. ulimit of 1) |
[jira] [Commented] (HBASE-21814) Remove the TODO in AccessControlLists#addUserPermission
[
https://issues.apache.org/jira/browse/HBASE-21814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768988#comment-16768988
]
Guanghao Zhang commented on HBASE-21814:
Copied the comments from HBASE-18500.
https://issues.apache.org/jira/browse/HBASE-18500?focusedCommentId=16121382&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16121382
https://issues.apache.org/jira/browse/HBASE-18500?focusedCommentId=16121630&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16121630
> Remove the TODO in AccessControlLists#addUserPermission
> ---
>
> Key: HBASE-21814
> URL: https://issues.apache.org/jira/browse/HBASE-21814
> Project: HBase
> Issue Type: Improvement
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21814.master.001.patch,
> HBASE-21814.master.001.patch, HBASE-21814.master.002.patch,
> HBASE-21814.master.002.patch
>
>
> The TODO was added by me. Because this method happens within the RS. The old
> impl use a login user(User.runAsLoginUser where the login user is the user
> who started RS process) to call Table.put(). And it will check the permission
> when put record to ACL table. At RpcServer we have a ThreadLocal where we
> keep the CallContext and inside that the current RPC called user info is set.
> We need Table.put(List) to change to a new thread and and so old
> ThreadLocal variable is not accessible and so it looks as if no Rpc context
> and we were relying on the super user who starts the RS process.
>
> {code:java}
> User.runAsLoginUser(new PrivilegedExceptionAction() {
> @Override
> public Void run() throws Exception {
>
> AccessControlLists.addUserPermission(regionEnv.getConfiguration(), perm,
> regionEnv.getTable(AccessControlLists.ACL_TABLE_NAME),
> request.getMergeExistingPermissions());
> return null;
> }
> });
> {code}
>
> But after HBASE-21739, no need to User.runAsLoginUser. Because we will call
> Admin method to grant/revoke. And this will be execute in master and use the
> master user(the user who started master process) to call Table.put. So this
> is not a problem now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21906: -- Fix Version/s: (was: 2.0.5) > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1 > -- > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection
[
https://issues.apache.org/jira/browse/HBASE-21717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768993#comment-16768993
]
Duo Zhang commented on HBASE-21717:
---
{quote}
I'd suggest you shop these Table/Connection API changes over on the dev list.;
follks will be interested in changes this user-facing.
{quote}
Will do this after I finish replacing the sync implementation. It can reduce
our client code base a lot.
> Implement Connection based on AsyncConnection
> -
>
> Key: HBASE-21717
> URL: https://issues.apache.org/jira/browse/HBASE-21717
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-21717-HBASE-21512-v1.patch,
> HBASE-21717-HBASE-21512.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21906: -- Summary: Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1 (was: Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0) > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1 > -- > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.5, 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768989#comment-16768989 ] Duo Zhang commented on HBASE-21906: --- OK, fine... > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1 > -- > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21874) Bucket cache on Persistent memory
[
https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768949#comment-16768949
]
Anoop Sam John edited comment on HBASE-21874 at 2/15/19 6:03 AM:
-
bq.Why add the configurable buffer size? That seems to be what most of the
patch is about which is distracting.
We can remove that part if it is distracting but it may be needed if you need
to create bigger sized cache. It seems like a java restriction from mmapping
buffers.
Now the PmemIOEngine uses the FileMmapEngine ( we can make isPersistent -
false), but it is simple way to show how we can show a replacement of DRAM
IOEngine. But pls note in FileMmapEngine
{code:java}
return deserializer.deserialize(new SingleByteBuff(ByteBuffer.wrap(dst)), true,
MemoryType.EXCLUSIVE);{code}
where as here in PmemIOEngine
{code:java}
return deserializer.deserialize(dstBuffer, true, MemoryType.SHARED);{code}
So it becomes a direct replacement of the DRAM based IOEngine. ( you don't copy
the buffers onheap)
bq. I do not see any dependency on pmem libs, such as this one: [pmem
java|https://github.com/pmem/llpl],
These libraries are for guaranteeing the persistence nature in the underlying
devices after power cycles. We are not trying to have a persistent based cache
where we need to regain the data back after a restart. The llpl library that
you pointed is a Java wrapper on
[http://pmem.io/.|http://pmem.io/]
This native library assures durability by memory mapping the file on the Pmem
device.
See the notes here (Copied from https://pmem.io/pmdk/)
{code:java}
The Persistent Memory Development Kit, PMDK, is a growing collection of
libraries which have been developed for various use cases, tuned, validated to
production quality, and thoroughly documented. These libraries build on the
Direct Access (DAX) feature available in both Linux and Windows, which allows
applications direct load/store access to persistent memory by memory-mapping
files on a persistent memory aware file system.{code}
So Java's memory mapping itself allows us to get that capability.
If we want the persistence nature of the cache then yes we need to go with LLPL
library but that can be taken as next step.
was (Author: ram_krish):
bq.Why add the configurable buffer size? That seems to be what most of the
patch is about which is distracting.
We can remove that part if it is distracting but it may be needed if you need
to create bigger sized cache. It seems like a java restriction from mmapping
buffers.
Now the PmemIOEngine uses the FileMmapEngine ( we can make isPersistent -
false), but it is simple way to show how we can show a replacement of DRAM
IOEngine. But pls note in FileMmapEngine
{code:java}
return deserializer.deserialize(new SingleByteBuff(ByteBuffer.wrap(dst)), true,
MemoryType.EXCLUSIVE);{code}
where as here in PmemIOEngine
{code:java}
return deserializer.deserialize(dstBuffer, true, MemoryType.SHARED);{code}
So it becomes a direct replacement of the DRAM based IOEngine. ( you don't copy
the buffers onheap)
bq. I do not see any dependency on pmem libs, such as this one: [pmem
java|https://github.com/pmem/llpl],
These libraries are for guaranteeing the persistence nature in the underlying
devices after power cycles. We are not trying to have a persistent based cache
where we need to regain the data back after a restart. The llpl library that
you pointed is a Java wrapper on
[http://pmem.io/.|http://pmem.io/]
This native library assures durability by memory mapping the file on the Pmem
device.
See the notes here
{code:java}
The Persistent Memory Development Kit, PMDK, is a growing collection of
libraries which have been developed for various use cases, tuned, validated to
production quality, and thoroughly documented. These libraries build on the
Direct Access (DAX) feature available in both Linux and Windows, which allows
applications direct load/store access to persistent memory by memory-mapping
files on a persistent memory aware file system.{code}
So Java's memory mapping itself allows us to get that capability.
If we want the persistence nature of the cache then yes we need to go with LLPL
library but that can be taken as next step.
> Bucket cache on Persistent memory
> -
>
> Key: HBASE-21874
> URL: https://issues.apache.org/jira/browse/HBASE-21874
> Project: HBase
> Issue Type: New Feature
> Components: BucketCache
>Affects Versions: 3.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png
>
>
> Non volatile persistent memory devices are byte addressable like DRAM (for
> eg. Intel DCPMM). Bucket cache
[jira] [Comment Edited] (HBASE-21874) Bucket cache on Persistent memory
[
https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768936#comment-16768936
]
Anoop Sam John edited comment on HBASE-21874 at 2/15/19 6:01 AM:
-
bq.but PmemIOEngine extends FileMmapEngine which advertises itself as persistent
We will need to make isPersistent () to be false in PmemIOEngine for now unless
we make sure the persistent nature been tested wrt FT and perf. As a 1st step
we thought of adding it an IOEngine almost same perf with off heap engine and
with lower cost!
You can see the FileIOEngine and FileMmapIOEngine implements sync()
{code}
public void sync() throws IOException {
if (fileChannel != null) {
fileChannel.force(true);
}
}
{code}
This is still happening for the PmemIOEngine also. Anyway the cache
persistence is valid if RS down gracefully. So that we can persist the blocks
info meta and on restart use that to rebuild the cache. So short ans is yes
still the persistence is there.
The pmem APIs are to make sure that the persistence been guaranteed even in
case of abrupt power downs!
was (Author: anoop.hbase):
bq.but PmemIOEngine extends FileMmapEngine which advertises itself as persistent
We will need to make isPersistent () to be false in PmemIOEngine for now unless
we make sure the persistent nature been used and tested. As a 1st step we
thought of adding it an IOEngine almost same perf with off heap engine and with
lower cost!
> Bucket cache on Persistent memory
> -
>
> Key: HBASE-21874
> URL: https://issues.apache.org/jira/browse/HBASE-21874
> Project: HBase
> Issue Type: New Feature
> Components: BucketCache
>Affects Versions: 3.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png
>
>
> Non volatile persistent memory devices are byte addressable like DRAM (for
> eg. Intel DCPMM). Bucket cache implementation can take advantage of this new
> memory type and can make use of the existing offheap data structures to serve
> data directly from this memory area without having to bring the data to
> onheap.
> The patch is a new IOEngine implementation that works with the persistent
> memory.
> Note : Here we don't make use of the persistence nature of the device and
> just make use of the big memory it provides.
> Performance numbers to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768951#comment-16768951 ] stack edited comment on HBASE-21906 at 2/15/19 5:18 AM: Patch looks good. Its a bit exotic but lets try it.- +1 for branch-2.0.- ... changed my mind. I think this might be too exotic for a mature branch like branch-2.0. Lets not backport it there. was (Author: stack): Patch looks good. Its a bit exotic but lets try it. +1 for branch-2.0. > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1/branch-2.0 > - > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.5, 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory
[
https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768949#comment-16768949
]
ramkrishna.s.vasudevan commented on HBASE-21874:
bq.Why add the configurable buffer size? That seems to be what most of the
patch is about which is distracting.
We can remove that part if it is distracting but it may be needed if you need
to create bigger sized cache. It seems like a java restriction from mmapping
buffers.
Now the PmemIOEngine uses the FileMmapEngine ( we can make isPersistent -
false), but it is simple way to show how we can show a replacement of DRAM
IOEngine. But pls note in FileMmapEngine
{code:java}
return deserializer.deserialize(new SingleByteBuff(ByteBuffer.wrap(dst)), true,
MemoryType.EXCLUSIVE);{code}
where as here in PmemIOEngine
{code:java}
return deserializer.deserialize(dstBuffer, true, MemoryType.SHARED);{code}
So it becomes a direct replacement of the DRAM based IOEngine. ( you don't copy
the buffers onheap)
bq. I do not see any dependency on pmem libs, such as this one: [pmem
java|https://github.com/pmem/llpl],
These libraries are for guaranteeing the persistence nature in the underlying
devices after power cycles. We are not trying to have a persistent based cache
where we need to regain the data back after a restart. The llpl library that
you pointed is a Java wrapper on
[http://pmem.io/.|http://pmem.io/]
This native library assures durability by memory mapping the file on the Pmem
device.
See the notes here
{code:java}
The Persistent Memory Development Kit, PMDK, is a growing collection of
libraries which have been developed for various use cases, tuned, validated to
production quality, and thoroughly documented. These libraries build on the
Direct Access (DAX) feature available in both Linux and Windows, which allows
applications direct load/store access to persistent memory by memory-mapping
files on a persistent memory aware file system.{code}
So Java's memory mapping itself allows us to get that capability.
If we want the persistence nature of the cache then yes we need to go with LLPL
library but that can be taken as next step.
> Bucket cache on Persistent memory
> -
>
> Key: HBASE-21874
> URL: https://issues.apache.org/jira/browse/HBASE-21874
> Project: HBase
> Issue Type: New Feature
> Components: BucketCache
>Affects Versions: 3.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png
>
>
> Non volatile persistent memory devices are byte addressable like DRAM (for
> eg. Intel DCPMM). Bucket cache implementation can take advantage of this new
> memory type and can make use of the existing offheap data structures to serve
> data directly from this memory area without having to bring the data to
> onheap.
> The patch is a new IOEngine implementation that works with the persistent
> memory.
> Note : Here we don't make use of the persistence nature of the device and
> just make use of the big memory it provides.
> Performance numbers to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768951#comment-16768951 ] stack commented on HBASE-21906: --- Patch looks good. Its a bit exotic but lets try it. +1 for branch-2.0. > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1/branch-2.0 > - > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.5, 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21814) Remove the TODO in AccessControlLists#addUserPermission
[
https://issues.apache.org/jira/browse/HBASE-21814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768950#comment-16768950
]
Guanghao Zhang commented on HBASE-21814:
Ping [~anoop.hbase]. If no objections, I will commit it today.
> Remove the TODO in AccessControlLists#addUserPermission
> ---
>
> Key: HBASE-21814
> URL: https://issues.apache.org/jira/browse/HBASE-21814
> Project: HBase
> Issue Type: Improvement
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21814.master.001.patch,
> HBASE-21814.master.001.patch, HBASE-21814.master.002.patch,
> HBASE-21814.master.002.patch
>
>
> The TODO was added by me. Because this method happens within the RS. The old
> impl use a login user(User.runAsLoginUser where the login user is the user
> who started RS process) to call Table.put(). And it will check the permission
> when put record to ACL table. At RpcServer we have a ThreadLocal where we
> keep the CallContext and inside that the current RPC called user info is set.
> We need Table.put(List) to change to a new thread and and so old
> ThreadLocal variable is not accessible and so it looks as if no Rpc context
> and we were relying on the super user who starts the RS process.
>
> {code:java}
> User.runAsLoginUser(new PrivilegedExceptionAction() {
> @Override
> public Void run() throws Exception {
>
> AccessControlLists.addUserPermission(regionEnv.getConfiguration(), perm,
> regionEnv.getTable(AccessControlLists.ACL_TABLE_NAME),
> request.getMergeExistingPermissions());
> return null;
> }
> });
> {code}
>
> But after HBASE-21739, no need to User.runAsLoginUser. Because we will call
> Admin method to grant/revoke. And this will be execute in master and use the
> master user(the user who started master process) to call Table.put. So this
> is not a problem now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21898) Release 1.2.11
[ https://issues.apache.org/jira/browse/HBASE-21898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768933#comment-16768933 ] Sean Busbey commented on HBASE-21898: - * updated version numbers and CHANGES * compat report looks fine * [recent flaky report looks okay|https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/job/branch-1.2/187/artifact/dashboard.html] nightly failed today, but it looks like a timing issue on the test. yesterday was fine and there's no change. > Release 1.2.11 > -- > > Key: HBASE-21898 > URL: https://issues.apache.org/jira/browse/HBASE-21898 > Project: HBase > Issue Type: Task > Components: community >Affects Versions: 1.2.11 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Fix For: 1.2.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory
[ https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768936#comment-16768936 ] Anoop Sam John commented on HBASE-21874: bq.but PmemIOEngine extends FileMmapEngine which advertises itself as persistent We will need to make isPersistent () to be false in PmemIOEngine for now unless we make sure the persistent nature been used and tested. As a 1st step we thought of adding it an IOEngine almost same perf with off heap engine and with lower cost! > Bucket cache on Persistent memory > - > > Key: HBASE-21874 > URL: https://issues.apache.org/jira/browse/HBASE-21874 > Project: HBase > Issue Type: New Feature > Components: BucketCache >Affects Versions: 3.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png > > > Non volatile persistent memory devices are byte addressable like DRAM (for > eg. Intel DCPMM). Bucket cache implementation can take advantage of this new > memory type and can make use of the existing offheap data structures to serve > data directly from this memory area without having to bring the data to > onheap. > The patch is a new IOEngine implementation that works with the persistent > memory. > Note : Here we don't make use of the persistence nature of the device and > just make use of the big memory it provides. > Performance numbers to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory
[ https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768931#comment-16768931 ] Anoop Sam John commented on HBASE-21874: bq.Why add the configurable buffer size? That seems to be what most of the patch is about which is distracting. That is not directly related with this new IOEngine patch. We have 4 MB sized BB chunks created when offheap/filemmap IOEngines. In case of mmap, this puts some restriction on the total cache size that can be used. There seems a cap on the #mmaped regions.. So we tried with some cache size > 250 GB (Do not remember the number exactly) the mmap calls were failing.. For Pmem mmap, it can be bigger sized BB chunks than 4 MB.. Might be we can remove that part from this patch and make it smaller. > Bucket cache on Persistent memory > - > > Key: HBASE-21874 > URL: https://issues.apache.org/jira/browse/HBASE-21874 > Project: HBase > Issue Type: New Feature > Components: BucketCache >Affects Versions: 3.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png > > > Non volatile persistent memory devices are byte addressable like DRAM (for > eg. Intel DCPMM). Bucket cache implementation can take advantage of this new > memory type and can make use of the existing offheap data structures to serve > data directly from this memory area without having to bring the data to > onheap. > The patch is a new IOEngine implementation that works with the persistent > memory. > Note : Here we don't make use of the persistence nature of the device and > just make use of the big memory it provides. > Performance numbers to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768921#comment-16768921
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #101 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/101/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/101//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/101//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/101//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21906: -- Status: Patch Available (was: Open) > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1/branch-2.0 > - > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.5, 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768917#comment-16768917 ] Duo Zhang commented on HBASE-21906: --- [~stack] PTAL sir. > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1/branch-2.0 > - > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.5, 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0
[ https://issues.apache.org/jira/browse/HBASE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21906: -- Attachment: HBASE-21906-branch-2.1.patch > Backport the CallQueueTooBigException related changes in HBASE-21875 to > branch-2.1/branch-2.0 > - > > Key: HBASE-21906 > URL: https://issues.apache.org/jira/browse/HBASE-21906 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.5, 2.1.4 > > Attachments: HBASE-21906-branch-2.1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21898) Release 1.2.11
[ https://issues.apache.org/jira/browse/HBASE-21898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768914#comment-16768914 ] Sean Busbey commented on HBASE-21898: - git and jira line up > Release 1.2.11 > -- > > Key: HBASE-21898 > URL: https://issues.apache.org/jira/browse/HBASE-21898 > Project: HBase > Issue Type: Task > Components: community >Affects Versions: 1.2.11 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Fix For: 1.2.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21875) Change the retry logic in RSProcedureDispatcher to 'retry by default, only if xxx'
[ https://issues.apache.org/jira/browse/HBASE-21875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21875: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch-2.2+. Thanks all for reviewing. > Change the retry logic in RSProcedureDispatcher to 'retry by default, only if > xxx' > -- > > Key: HBASE-21875 > URL: https://issues.apache.org/jira/browse/HBASE-21875 > Project: HBase > Issue Type: Improvement > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > Attachments: HBASE-21875-branch-2.1.patch, HBASE-21875-v1.patch, > HBASE-21875-v2.patch, HBASE-21875-v3.patch, HBASE-21875-v4.patch, > HBASE-21875.patch > > > For now it is not retry by default, only if xxx. > In executeProcedures, we will only throw a fixed set of exception, so we > should change to retry by default, and check for the exceptions which we do > not need to retry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21782) LoadIncrementalHFiles should not be IA.Public
[
https://issues.apache.org/jira/browse/HBASE-21782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768899#comment-16768899
]
Hudson commented on HBASE-21782:
Results for branch master
[build #797 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/797/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/797//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/797//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/797//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> LoadIncrementalHFiles should not be IA.Public
> -
>
> Key: HBASE-21782
> URL: https://issues.apache.org/jira/browse/HBASE-21782
> Project: HBase
> Issue Type: Task
> Components: mapreduce
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-21782-v1.patch, HBASE-21782.patch
>
>
> It is an implementation class, so some of the methods which are only supposed
> to be used by replication sink are also public to users. And it exposes
> methods which take Table and Connection as parameter and inside the
> implementation we assume that they are HTable and ConnectionImplementation,
> which will be a pain when we want to replace the sync client implementation
> with async client.
> Here I think we should make the implementation class as
> IA.LimitPrivate(TOOL), and introduce an interface for bulking hfiles
> programmatically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21906) Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0
Duo Zhang created HBASE-21906: - Summary: Backport the CallQueueTooBigException related changes in HBASE-21875 to branch-2.1/branch-2.0 Key: HBASE-21906 URL: https://issues.apache.org/jira/browse/HBASE-21906 Project: HBase Issue Type: Sub-task Components: proc-v2 Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 2.0.5, 2.1.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21900) Infinite loop in AsyncMetaRegionLocator if we can not get the location for meta
[
https://issues.apache.org/jira/browse/HBASE-21900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768898#comment-16768898
]
Hudson commented on HBASE-21900:
Results for branch master
[build #797 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/797/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/797//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/797//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/797//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Infinite loop in AsyncMetaRegionLocator if we can not get the location for
> meta
> ---
>
> Key: HBASE-21900
> URL: https://issues.apache.org/jira/browse/HBASE-21900
> Project: HBase
> Issue Type: Bug
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21900.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21872) Clean up getBytes() calls without charsets provided
[
https://issues.apache.org/jira/browse/HBASE-21872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768895#comment-16768895
]
Josh Elser commented on HBASE-21872:
Whoopsies. Will revert and reapply in the AM.
> Clean up getBytes() calls without charsets provided
> ---
>
> Key: HBASE-21872
> URL: https://issues.apache.org/jira/browse/HBASE-21872
> Project: HBase
> Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 3.0.0
>
> Attachments: HBASE-21782.001.patch, HBASE-21782.002.patch,
> HBASE-21782.003.patch, HBASE-21872.004.patch
>
>
> As we saw over in HBASE-21201, the use of {{String.getBytes()}} without a
> Charset can result is some compiler warnings. Let's just get rid of these
> calls. There are only a handful anymore in master.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21875) Change the retry logic in RSProcedureDispatcher to 'retry by default, only if xxx'
[ https://issues.apache.org/jira/browse/HBASE-21875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768889#comment-16768889 ] Guanghao Zhang commented on HBASE-21875: +1 > Change the retry logic in RSProcedureDispatcher to 'retry by default, only if > xxx' > -- > > Key: HBASE-21875 > URL: https://issues.apache.org/jira/browse/HBASE-21875 > Project: HBase > Issue Type: Improvement > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > Attachments: HBASE-21875-branch-2.1.patch, HBASE-21875-v1.patch, > HBASE-21875-v2.patch, HBASE-21875-v3.patch, HBASE-21875-v4.patch, > HBASE-21875.patch > > > For now it is not retry by default, only if xxx. > In executeProcedures, we will only throw a fixed set of exception, so we > should change to retry by default, and check for the exceptions which we do > not need to retry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21872) Clean up getBytes() calls without charsets provided
[
https://issues.apache.org/jira/browse/HBASE-21872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768878#comment-16768878
]
Duo Zhang edited comment on HBASE-21872 at 2/15/19 2:15 AM:
{noformat}
commit 3d4e1d57e57edd9c23e83048e5d376bff2270859
Author: Josh Elser
Date: Mon Feb 11 13:19:23 2019 -0500
HBASE-21782 Use a call that defaults to UTF-8 charset for string to byte
encoding
Signed-off-by: Sean Busbey
{noformat}
Wrong jira id, folks.
was (Author: apache9):
{quote}
commit 3d4e1d57e57edd9c23e83048e5d376bff2270859 (HEAD -> master, xiaomi/master,
origin/master, origin/HEAD, asf/master)
Author: Josh Elser
Date: Mon Feb 11 13:19:23 2019 -0500
HBASE-21782 Use a call that defaults to UTF-8 charset for string to byte
encoding
Signed-off-by: Sean Busbey
{quote}
Wrong jira id, folks.
> Clean up getBytes() calls without charsets provided
> ---
>
> Key: HBASE-21872
> URL: https://issues.apache.org/jira/browse/HBASE-21872
> Project: HBase
> Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 3.0.0
>
> Attachments: HBASE-21782.001.patch, HBASE-21782.002.patch,
> HBASE-21782.003.patch, HBASE-21872.004.patch
>
>
> As we saw over in HBASE-21201, the use of {{String.getBytes()}} without a
> Charset can result is some compiler warnings. Let's just get rid of these
> calls. There are only a handful anymore in master.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21872) Clean up getBytes() calls without charsets provided
[
https://issues.apache.org/jira/browse/HBASE-21872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768878#comment-16768878
]
Duo Zhang commented on HBASE-21872:
---
{quote}
commit 3d4e1d57e57edd9c23e83048e5d376bff2270859 (HEAD -> master, xiaomi/master,
origin/master, origin/HEAD, asf/master)
Author: Josh Elser
Date: Mon Feb 11 13:19:23 2019 -0500
HBASE-21782 Use a call that defaults to UTF-8 charset for string to byte
encoding
Signed-off-by: Sean Busbey
{quote}
Wrong jira id, folks.
> Clean up getBytes() calls without charsets provided
> ---
>
> Key: HBASE-21872
> URL: https://issues.apache.org/jira/browse/HBASE-21872
> Project: HBase
> Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 3.0.0
>
> Attachments: HBASE-21782.001.patch, HBASE-21782.002.patch,
> HBASE-21782.003.patch, HBASE-21872.004.patch
>
>
> As we saw over in HBASE-21201, the use of {{String.getBytes()}} without a
> Charset can result is some compiler warnings. Let's just get rid of these
> calls. There are only a handful anymore in master.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21744) timeout for server list refresh calls
[
https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768830#comment-16768830
]
Hadoop QA commented on HBASE-21744:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
36s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
30s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 39s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
4s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}122m
19s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
45s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21744 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12958785/HBASE-21744.04.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 745446bfd619 4.4.0-131-generic #157~14.04.1-Ubuntu SMP Fri Jul
13 08:53:17 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master
[jira] [Commented] (HBASE-21901) update branch-1.2 ref guide for 1.2.11 release
[ https://issues.apache.org/jira/browse/HBASE-21901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768818#comment-16768818 ] Hudson commented on HBASE-21901: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1206 (See [https://builds.apache.org/job/HBase-1.2-IT/1206/]) HBASE-21901 update ref guide for 1.2.11 release (busbey: [https://github.com/apache/hbase/commit/f8e1a8dd2a43050eb35db9ee734cdf661bea2fb8]) * (edit) src/main/asciidoc/_chapters/troubleshooting.adoc * (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * (edit) src/main/asciidoc/_chapters/ops_mgt.adoc * (edit) src/main/asciidoc/_chapters/appendix_hfile_format.adoc * (edit) pom.xml * (edit) src/main/asciidoc/_chapters/architecture.adoc * (edit) src/main/asciidoc/book.adoc * (delete) src/main/asciidoc/_chapters/spark.adoc * (edit) src/main/asciidoc/_chapters/developer.adoc * (edit) src/main/asciidoc/_chapters/configuration.adoc > update branch-1.2 ref guide for 1.2.11 release > -- > > Key: HBASE-21901 > URL: https://issues.apache.org/jira/browse/HBASE-21901 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 1.2.11 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 1.2.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21900) Infinite loop in AsyncMetaRegionLocator if we can not get the location for meta
[
https://issues.apache.org/jira/browse/HBASE-21900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768806#comment-16768806
]
Hudson commented on HBASE-21900:
Results for branch branch-2
[build #1684 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Infinite loop in AsyncMetaRegionLocator if we can not get the location for
> meta
> ---
>
> Key: HBASE-21900
> URL: https://issues.apache.org/jira/browse/HBASE-21900
> Project: HBase
> Issue Type: Bug
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21900.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19889) Revert Workaround: Purge User API building from branch-2 so can make a beta-1
[
https://issues.apache.org/jira/browse/HBASE-19889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768807#comment-16768807
]
Hudson commented on HBASE-19889:
Results for branch branch-2
[build #1684 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1684//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Revert Workaround: Purge User API building from branch-2 so can make a beta-1
> -
>
> Key: HBASE-19889
> URL: https://issues.apache.org/jira/browse/HBASE-19889
> Project: HBase
> Issue Type: Sub-task
> Components: website
>Reporter: stack
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: hbase-19889.branch-2.0.001.patch,
> hbase-19889.branch-2.0.002.patch, hbase-19889.branch-2.1.001.patch
>
>
> Root fix looks to be -HBASE-19780-
> Let me try it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21817) handle corrupted cells like other corrupted WAL cases
[
https://issues.apache.org/jira/browse/HBASE-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768803#comment-16768803
]
Hadoop QA commented on HBASE-21817:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
35s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
37s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
18s{color} | {color:red} hbase-server: The patch generated 2 new + 118
unchanged - 2 fixed = 120 total (was 120) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
36s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 31s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
43s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}146m
41s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
43s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}198m 59s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21817 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12958776/HBASE-21817.05.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 109d5507e3e5 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct
31 10:55:11 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 3d4e1d57e5 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f
[jira] [Commented] (HBASE-19889) Revert Workaround: Purge User API building from branch-2 so can make a beta-1
[
https://issues.apache.org/jira/browse/HBASE-19889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768800#comment-16768800
]
Hudson commented on HBASE-19889:
Results for branch branch-2.2
[build #42 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Revert Workaround: Purge User API building from branch-2 so can make a beta-1
> -
>
> Key: HBASE-19889
> URL: https://issues.apache.org/jira/browse/HBASE-19889
> Project: HBase
> Issue Type: Sub-task
> Components: website
>Reporter: stack
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: hbase-19889.branch-2.0.001.patch,
> hbase-19889.branch-2.0.002.patch, hbase-19889.branch-2.1.001.patch
>
>
> Root fix looks to be -HBASE-19780-
> Let me try it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21900) Infinite loop in AsyncMetaRegionLocator if we can not get the location for meta
[
https://issues.apache.org/jira/browse/HBASE-21900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768799#comment-16768799
]
Hudson commented on HBASE-21900:
Results for branch branch-2.2
[build #42 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/42//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Infinite loop in AsyncMetaRegionLocator if we can not get the location for
> meta
> ---
>
> Key: HBASE-21900
> URL: https://issues.apache.org/jira/browse/HBASE-21900
> Project: HBase
> Issue Type: Bug
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21900.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-21901) update branch-1.2 ref guide for 1.2.11 release
[ https://issues.apache.org/jira/browse/HBASE-21901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-21901. - Resolution: Fixed > update branch-1.2 ref guide for 1.2.11 release > -- > > Key: HBASE-21901 > URL: https://issues.apache.org/jira/browse/HBASE-21901 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 1.2.11 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 1.2.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21817) handle corrupted cells like other corrupted WAL cases
[
https://issues.apache.org/jira/browse/HBASE-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768776#comment-16768776
]
Hadoop QA commented on HBASE-21817:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
7s{color} | {color:red} hbase-server: The patch generated 3 new + 118 unchanged
- 2 fixed = 121 total (was 120) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
9s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 44s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
45s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}121m
49s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
53s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}168m 1s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21817 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12958775/HBASE-21817.05.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 5a3351a410b2 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 3d4e1d57e5 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfde
[jira] [Updated] (HBASE-21905) TestFIFOCompactionPolicy is flaky (branch-1)
[ https://issues.apache.org/jira/browse/HBASE-21905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21905: --- Attachment: org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > TestFIFOCompactionPolicy is flaky (branch-1) > > > Key: HBASE-21905 > URL: https://issues.apache.org/jira/browse/HBASE-21905 > Project: HBase > Issue Type: Test >Affects Versions: 1.5.0 >Reporter: Andrew Purtell >Priority: Major > Fix For: 1.5.1 > > Attachments: > org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > > > java.lang.IllegalArgumentException , overlaps with > For example: > [ERROR] > testFIFOCompactionPolicyExpiredEmptyHFiles(org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy) > Time elapsed: 3.321 s <<< ERROR! > java.io.IOException: > java.io.IOException: > [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69, > > hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c65648691f614b2d8dd4b586c5923bfe] > overlaps with > [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69] > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2438) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124) > at > org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:297) > at > org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:277) > Caused by: java.lang.IllegalArgumentException: > [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69, > > hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c65648691f614b2d8dd4b586c5923bfe] > overlaps with > [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69] > at > com.google.common.base.Preconditions.checkArgument(Preconditions.java:119) > at > org.apache.hadoop.hbase.regionserver.HStore.addToCompactingFiles(HStore.java:1824) > at > org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(HStore.java:1798) > at > org.apache.hadoop.hbase.regionserver.CompactSplitThread.selectCompaction(CompactSplitThread.java:415) > at > org.apache.hadoop.hbase.regionserver.CompactSplitThread.requestCompactionInternal(CompactSplitThread.java:388) > at > org.apache.hadoop.hbase.regionserver.CompactSplitThread.requestCompactionInternal(CompactSplitThread.java:317) > at > org.apache.hadoop.hbase.regionserver.CompactSplitThread.requestCompaction(CompactSplitThread.java:306) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.compactRegion(RSRpcServices.java:1513) > at > org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:23649) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2380) > ... 3 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21905) TestFIFOCompactionPolicy is flaky (branch-1)
Andrew Purtell created HBASE-21905: -- Summary: TestFIFOCompactionPolicy is flaky (branch-1) Key: HBASE-21905 URL: https://issues.apache.org/jira/browse/HBASE-21905 Project: HBase Issue Type: Test Affects Versions: 1.5.0 Reporter: Andrew Purtell Fix For: 1.5.1 java.lang.IllegalArgumentException , overlaps with For example: [ERROR] testFIFOCompactionPolicyExpiredEmptyHFiles(org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy) Time elapsed: 3.321 s <<< ERROR! java.io.IOException: java.io.IOException: [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69, hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c65648691f614b2d8dd4b586c5923bfe] overlaps with [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69] at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2438) at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124) at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:297) at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:277) Caused by: java.lang.IllegalArgumentException: [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69, hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c65648691f614b2d8dd4b586c5923bfe] overlaps with [hdfs://localhost:41525/user/apurtell/test-data/734de07d-1f22-46a9-a1f5-96ad4578450b/data/default/testFIFOCompactionPolicyExpiredEmptyHFiles/c4f673438e09d7ef5a9b79b363639cde/f/c0c5836c1f714f78847cf00326586b69] at com.google.common.base.Preconditions.checkArgument(Preconditions.java:119) at org.apache.hadoop.hbase.regionserver.HStore.addToCompactingFiles(HStore.java:1824) at org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(HStore.java:1798) at org.apache.hadoop.hbase.regionserver.CompactSplitThread.selectCompaction(CompactSplitThread.java:415) at org.apache.hadoop.hbase.regionserver.CompactSplitThread.requestCompactionInternal(CompactSplitThread.java:388) at org.apache.hadoop.hbase.regionserver.CompactSplitThread.requestCompactionInternal(CompactSplitThread.java:317) at org.apache.hadoop.hbase.regionserver.CompactSplitThread.requestCompaction(CompactSplitThread.java:306) at org.apache.hadoop.hbase.regionserver.RSRpcServices.compactRegion(RSRpcServices.java:1513) at org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:23649) at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2380) ... 3 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21884) Fix box/unbox findbugs warning in secure bulk load
[
https://issues.apache.org/jira/browse/HBASE-21884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-21884:
---
Fix Version/s: (was: 1.5.1)
1.5.0
> Fix box/unbox findbugs warning in secure bulk load
> --
>
> Key: HBASE-21884
> URL: https://issues.apache.org/jira/browse/HBASE-21884
> Project: HBase
> Issue Type: Task
>Affects Versions: 3.0.0, 1.5.0, 2.2.0, 2.1.1, 2.0.3, 2.1.2, 2.0.4, 1.4.10,
> 1.3.4, 1.2.11, 2.3.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.10, 1.3.4, 1.2.11, 2.3.0,
> 2.1.4, 2.0.6
>
> Attachments: HBASE-21884-branch-1.v0.patch,
> HBASE-21884-master.v0.patch, HBASE-21884-master.v1.patch
>
>
> {code}
> ReasonTests
> FindBugs module:hbase-server
> Boxed value is unboxed and then immediately reboxed in
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint.incrementUgiReference(UserGroupInformation)
> At SecureBulkLoadEndpoint.java:then immediately reboxed in
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint.incrementUgiReference(UserGroupInformation)
> At SecureBulkLoadEndpoint.java:[line 268]
> {code}
> Looking at branch-2 and master I suspect we're doing the same wasteful
> operation but findbugs can't see it through the lambda definition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21904) TestSimpleRpcScheduler is still flaky (branch-1)
[ https://issues.apache.org/jira/browse/HBASE-21904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768768#comment-16768768 ] Andrew Purtell commented on HBASE-21904: Fails on Linux hosts, not seen on MacOS > TestSimpleRpcScheduler is still flaky (branch-1) > > > Key: HBASE-21904 > URL: https://issues.apache.org/jira/browse/HBASE-21904 > Project: HBase > Issue Type: Test >Affects Versions: 1.5.0 >Reporter: Andrew Purtell >Priority: Major > Fix For: 1.5.1 > > Attachments: > org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler-output.txt > > > Flaky wait condition, unclear if it's the wait condition or the underlying > functionality that is the problem. > [ERROR] > testSoftAndHardQueueLimits(org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler) > Time elapsed: 0.228 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler.testSoftAndHardQueueLimits(TestSimpleRpcScheduler.java:380) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21861) Handle the missing file issues from the Linkchecker job
[ https://issues.apache.org/jira/browse/HBASE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768772#comment-16768772 ] Sean Busbey commented on HBASE-21861: - okay, no rush from me then. I don't use RDM for release notes in the 1.2 line, so I don't need this jira in any particular state. > Handle the missing file issues from the Linkchecker job > --- > > Key: HBASE-21861 > URL: https://issues.apache.org/jira/browse/HBASE-21861 > Project: HBase > Issue Type: Sub-task >Reporter: Sakthi >Assignee: Sakthi >Priority: Major > Fix For: 1.2.11 > > Attachments: hbase-21861.branch-1.2.001.patch, > hbase-21861.branch-2.0.001.patch, hbase-21861.branch-2.1.001.patch, > hbase-21861.master.001.patch > > > The parent jira contains the numbers for the missing files. This jira is to > track specifically the fixes in that aspect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21904) TestSimpleRpcScheduler is still flaky (branch-1)
[ https://issues.apache.org/jira/browse/HBASE-21904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21904: --- Attachment: org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler-output.txt > TestSimpleRpcScheduler is still flaky (branch-1) > > > Key: HBASE-21904 > URL: https://issues.apache.org/jira/browse/HBASE-21904 > Project: HBase > Issue Type: Test >Affects Versions: 1.5.0 >Reporter: Andrew Purtell >Priority: Major > Fix For: 1.5.1 > > Attachments: > org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler-output.txt > > > Flaky wait condition, unclear if it's the wait condition or the underlying > functionality that is the problem. > [ERROR] > testSoftAndHardQueueLimits(org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler) > Time elapsed: 0.228 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler.testSoftAndHardQueueLimits(TestSimpleRpcScheduler.java:380) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21904) TestSimpleRpcScheduler is still flaky (branch-1)
Andrew Purtell created HBASE-21904: -- Summary: TestSimpleRpcScheduler is still flaky (branch-1) Key: HBASE-21904 URL: https://issues.apache.org/jira/browse/HBASE-21904 Project: HBase Issue Type: Test Affects Versions: 1.5.0 Reporter: Andrew Purtell Fix For: 1.5.1 Attachments: org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler-output.txt Flaky wait condition, unclear if it's the wait condition or the underlying functionality that is the problem. [ERROR] testSoftAndHardQueueLimits(org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler) Time elapsed: 0.228 s <<< FAILURE! java.lang.AssertionError at org.apache.hadoop.hbase.ipc.TestSimpleRpcScheduler.testSoftAndHardQueueLimits(TestSimpleRpcScheduler.java:380) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21861) Handle the missing file issues from the Linkchecker job
[ https://issues.apache.org/jira/browse/HBASE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768679#comment-16768679 ] Sakthi edited comment on HBASE-21861 at 2/14/19 10:28 PM: -- Yes 1.2 is done Sean. I'm still working on Master though. was (Author: jatsakthi): Yes 1.2 is done Sean. I'm still working on Master though. On Thu, Feb 14, 2019 at 12:12 PM Peter Somogyi (JIRA) > Handle the missing file issues from the Linkchecker job > --- > > Key: HBASE-21861 > URL: https://issues.apache.org/jira/browse/HBASE-21861 > Project: HBase > Issue Type: Sub-task >Reporter: Sakthi >Assignee: Sakthi >Priority: Major > Fix For: 1.2.11 > > Attachments: hbase-21861.branch-1.2.001.patch, > hbase-21861.branch-2.0.001.patch, hbase-21861.branch-2.1.001.patch, > hbase-21861.master.001.patch > > > The parent jira contains the numbers for the missing files. This jira is to > track specifically the fixes in that aspect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory
[ https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768765#comment-16768765 ] Vladimir Rodionov commented on HBASE-21874: --- Yes, this patch puzzles me a bit as well. It seems it requires file system on top of PMEM (application accesses pmem using standard fs/block device API and does not work directly with pmem as with regular RAM). I do not see any dependency on pmem libs, such as this one: [pmem java|https://github.com/pmem/llpl], for example, [~ram_krish]. > Bucket cache on Persistent memory > - > > Key: HBASE-21874 > URL: https://issues.apache.org/jira/browse/HBASE-21874 > Project: HBase > Issue Type: New Feature > Components: BucketCache >Affects Versions: 3.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png > > > Non volatile persistent memory devices are byte addressable like DRAM (for > eg. Intel DCPMM). Bucket cache implementation can take advantage of this new > memory type and can make use of the existing offheap data structures to serve > data directly from this memory area without having to bring the data to > onheap. > The patch is a new IOEngine implementation that works with the persistent > memory. > Note : Here we don't make use of the persistence nature of the device and > just make use of the big memory it provides. > Performance numbers to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768757#comment-16768757 ] Sean Busbey commented on HBASE-21903: - We could add downstream facing docs explaining the use of the tool from hbase-operator-tools and announce such on users@hbase. A big advantage is that ideally folks wouldn't have to upgrade their hbase install to use it. > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.4.10, 1.3.4 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory
[ https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768748#comment-16768748 ] Jean-Daniel Cryans commented on HBASE-21874: Hi Ram. Two questions: - Why add the configurable buffer size? That seems to be what most of the patch is about which is distracting. - You say that the patch doesn't make use of the persistent nature of the device, but PmemIOEngine extends FileMmapEngine which advertises itself as persistent so it does a few other things on top. I might be confused about what it implies but this is also confusing :) > Bucket cache on Persistent memory > - > > Key: HBASE-21874 > URL: https://issues.apache.org/jira/browse/HBASE-21874 > Project: HBase > Issue Type: New Feature > Components: BucketCache >Affects Versions: 3.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png > > > Non volatile persistent memory devices are byte addressable like DRAM (for > eg. Intel DCPMM). Bucket cache implementation can take advantage of this new > memory type and can make use of the existing offheap data structures to serve > data directly from this memory area without having to bring the data to > onheap. > The patch is a new IOEngine implementation that works with the persistent > memory. > Note : Here we don't make use of the persistence nature of the device and > just make use of the big memory it provides. > Performance numbers to follow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21744) timeout for server list refresh calls
[ https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768732#comment-16768732 ] Sergey Shelukhin commented on HBASE-21744: -- Hm... still cannot repro any of these test failures and logs look bogus. Some tests that fail appear to have no test history, so I wonder if they are broken and run only for this patch. Some seem to have HDFS errors on the log, or even setup issues connecting to stuff, and setup-time NPEs in test code. Locally, they pass. Not sure if this patch causes something bad or is just unlucky > timeout for server list refresh calls > -- > > Key: HBASE-21744 > URL: https://issues.apache.org/jira/browse/HBASE-21744 > Project: HBase > Issue Type: Improvement > Components: Zookeeper >Affects Versions: 3.0.0, 2.2.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-21744.01.patch, HBASE-21744.02.patch, > HBASE-21744.03.patch, HBASE-21744.patch > > > Not sure why yet, but we are seeing the case when cluster is in overall a bad > state, where after RS dies and deletes its znode, the notification looks like > it's lost, so the master doesn't detect the failure. ZK itself appears to be > healthy and doesn't report anything special. > After some other change is made to the server list, master rescans the list > and picks up the stale change. Might make sense to add a config that would > trigger the refresh if it hasn't happened for a while (e.g. 1 minute). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21744) timeout for server list refresh calls
[ https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21744: - Attachment: HBASE-21744.04.patch > timeout for server list refresh calls > -- > > Key: HBASE-21744 > URL: https://issues.apache.org/jira/browse/HBASE-21744 > Project: HBase > Issue Type: Improvement > Components: Zookeeper >Affects Versions: 3.0.0, 2.2.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-21744.01.patch, HBASE-21744.02.patch, > HBASE-21744.03.patch, HBASE-21744.04.patch, HBASE-21744.patch > > > Not sure why yet, but we are seeing the case when cluster is in overall a bad > state, where after RS dies and deletes its znode, the notification looks like > it's lost, so the master doesn't detect the failure. ZK itself appears to be > healthy and doesn't report anything special. > After some other change is made to the server list, master rescans the list > and picks up the stale change. Might make sense to add a config that would > trigger the refresh if it hasn't happened for a while (e.g. 1 minute). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768655#comment-16768655 ] churro morales commented on HBASE-21903: Would people using 1.x know to use operator tools? Seems like only those that use 2.x and want hbck support would have any knowledge about operator tools. > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.4.10, 1.3.4 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21866) Do not move the table to null rsgroup when creating an existing table
[
https://issues.apache.org/jira/browse/HBASE-21866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768708#comment-16768708
]
Xu Cang commented on HBASE-21866:
-
The patch looks really good to me.
One nit:
getException().getCause().getClass()
Can you double check if this will not cause nullPointerException in any chance?
I think you might want to call #hasException first.
> Do not move the table to null rsgroup when creating an existing table
> -
>
> Key: HBASE-21866
> URL: https://issues.apache.org/jira/browse/HBASE-21866
> Project: HBase
> Issue Type: Bug
> Components: proc-v2, rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Major
> Attachments: HBASE-21866.master.000.patch,
> HBASE-21866.master.001.patch
>
>
> By using the latest HBase master branch, the bug could be re-produced as:
> # create 't1', 'cf1'
> # create 't1', 'cf1'
> The following message is logged into HMaster's log:
> {code}
> INFO [PEWorker-12] rsgroup.RSGroupAdminServer: Moving table t1 to RSGroup
> null
> {code}
> This is a wrong action and instead, we should keep t1 as where it originally
> is.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21861) Handle the missing file issues from the Linkchecker job
[ https://issues.apache.org/jira/browse/HBASE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768679#comment-16768679 ] Sakthi commented on HBASE-21861: Yes 1.2 is done Sean. I'm still working on Master though. On Thu, Feb 14, 2019 at 12:12 PM Peter Somogyi (JIRA) > Handle the missing file issues from the Linkchecker job > --- > > Key: HBASE-21861 > URL: https://issues.apache.org/jira/browse/HBASE-21861 > Project: HBase > Issue Type: Sub-task >Reporter: Sakthi >Assignee: Sakthi >Priority: Major > Fix For: 1.2.11 > > Attachments: hbase-21861.branch-1.2.001.patch, > hbase-21861.branch-2.0.001.patch, hbase-21861.branch-2.1.001.patch, > hbase-21861.master.001.patch > > > The parent jira contains the numbers for the missing files. This jira is to > track specifically the fixes in that aspect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21861) Handle the missing file issues from the Linkchecker job
[ https://issues.apache.org/jira/browse/HBASE-21861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768676#comment-16768676 ] Peter Somogyi commented on HBASE-21861: --- 1.2 is done. [~jatsakthi], are there any other branches where similar change is needed? > Handle the missing file issues from the Linkchecker job > --- > > Key: HBASE-21861 > URL: https://issues.apache.org/jira/browse/HBASE-21861 > Project: HBase > Issue Type: Sub-task >Reporter: Sakthi >Assignee: Sakthi >Priority: Major > Fix For: 1.2.11 > > Attachments: hbase-21861.branch-1.2.001.patch, > hbase-21861.branch-2.0.001.patch, hbase-21861.branch-2.1.001.patch, > hbase-21861.master.001.patch > > > The parent jira contains the numbers for the missing files. This jira is to > track specifically the fixes in that aspect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21817) handle corrupted cells like other corrupted WAL cases
[ https://issues.apache.org/jira/browse/HBASE-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21817: - Attachment: (was: HBASE-21817.05.patch) > handle corrupted cells like other corrupted WAL cases > - > > Key: HBASE-21817 > URL: https://issues.apache.org/jira/browse/HBASE-21817 > Project: HBase > Issue Type: Bug > Components: wal >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Attachments: HBASE-21817.01.patch, HBASE-21817.02.patch, > HBASE-21817.03.patch, HBASE-21817.04.patch, HBASE-21817.04.patch, > HBASE-21817.05.patch, HBASE-21817.patch > > > See HBASE-21601 for context. > I looked at the code a bit but it will take a while to understand, so for now > I'm going to mitigate it by handling such cases like any other corrupted WAL > (via either skipErrors or CorruptedHLog exception) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21817) handle corrupted cells like other corrupted WAL cases
[ https://issues.apache.org/jira/browse/HBASE-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21817: - Attachment: HBASE-21817.05.patch > handle corrupted cells like other corrupted WAL cases > - > > Key: HBASE-21817 > URL: https://issues.apache.org/jira/browse/HBASE-21817 > Project: HBase > Issue Type: Bug > Components: wal >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Attachments: HBASE-21817.01.patch, HBASE-21817.02.patch, > HBASE-21817.03.patch, HBASE-21817.04.patch, HBASE-21817.04.patch, > HBASE-21817.05.patch, HBASE-21817.patch > > > See HBASE-21601 for context. > I looked at the code a bit but it will take a while to understand, so for now > I'm going to mitigate it by handling such cases like any other corrupted WAL > (via either skipErrors or CorruptedHLog exception) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21817) handle corrupted cells like other corrupted WAL cases
[ https://issues.apache.org/jira/browse/HBASE-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21817: - Attachment: HBASE-21817.05.patch > handle corrupted cells like other corrupted WAL cases > - > > Key: HBASE-21817 > URL: https://issues.apache.org/jira/browse/HBASE-21817 > Project: HBase > Issue Type: Bug > Components: wal >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Attachments: HBASE-21817.01.patch, HBASE-21817.02.patch, > HBASE-21817.03.patch, HBASE-21817.04.patch, HBASE-21817.04.patch, > HBASE-21817.05.patch, HBASE-21817.patch > > > See HBASE-21601 for context. > I looked at the code a bit but it will take a while to understand, so for now > I'm going to mitigate it by handling such cases like any other corrupted WAL > (via either skipErrors or CorruptedHLog exception) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvel Thirumoolan updated HBASE-21903: - Attachment: HBASE-21903-branch-1.3-addendum.patch > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.4.10, 1.3.4 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768656#comment-16768656 ] Thiruvel Thirumoolan commented on HBASE-21903: -- For 1.3, we have to cherry pick https://github.com/apache/hbase/commit/673e8092506cd7c2c09093a3d085dc197ff14f53 and then apply [^HBASE-21903-branch-1.3-addendum.patch] to it, which is changes to only unit test framework. For 1.4, the patch applies as is, so just cherry pick. > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.4.10, 1.3.4 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[
https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768646#comment-16768646
]
Sean Busbey commented on HBASE-21903:
-
Could we make the tool work with all of those versions while keeping it in the
{{hbase-operator-tools}} repo?
> Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
> --
>
> Key: HBASE-21903
> URL: https://issues.apache.org/jira/browse/HBASE-21903
> Project: HBase
> Issue Type: Task
> Components: Client, Compaction, tooling
>Affects Versions: 1.3.3, 1.4.9
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
>Priority: Major
> Fix For: 1.4.10, 1.3.4
>
>
> Our internal deployments are based on branch-1.3. We will be using the major
> compaction tool HBASE-19528 from [~churromorales] and the enhancements on top
> of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528
> to 1.3 and hence 1.4 as well. Since its a standalone tool without any other
> dependency or code changes, I believe that should be ok.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
Thiruvel Thirumoolan created HBASE-21903: Summary: Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 Key: HBASE-21903 URL: https://issues.apache.org/jira/browse/HBASE-21903 Project: HBase Issue Type: Task Components: Client, Compaction, tooling Affects Versions: 1.4.9, 1.3.3 Reporter: Thiruvel Thirumoolan Assignee: Thiruvel Thirumoolan Fix For: 1.4.10, 1.3.4 Our internal deployments are based on branch-1.3. We will be using the major compaction tool HBASE-19528 from [~churromorales] and the enhancements on top of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 to 1.3 and hence 1.4 as well. Since its a standalone tool without any other dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21623) ServerCrashProcedure can stomp on a RIT for a wrong server
[
https://issues.apache.org/jira/browse/HBASE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768632#comment-16768632
]
Sergey Shelukhin edited comment on HBASE-21623 at 2/14/19 7:28 PM:
---
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision
(and it couldn't care for them, cause whether it is updating the right or wrong
RIT, the latter would still be holding the region lock, so the situation is not
different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as follows (where each individual step looks safe from
lower-level races to me, given language-level sync)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
was (Author: sershe):
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as follows (where each individual step looks safe from
lower-level races to me, given language-level sync)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
> ServerCrashProcedure can stomp on a RIT for a wrong server
> --
>
> Key: HBASE-21623
> URL: https://issues.apache.org/jira/browse/HBASE-21623
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Attachments: HBASE-21623.patch
>
>
> A server died while some region was being opened on it; eventually the open
> failed, and the RIT procedure started retrying on a different server.
> However, by then SCP for the dying server had already obtained the region
> from the list of regions on the old server, and proceeded to overwrite
> whatever the RIT was doing with a new server.
> {noformat}
> 2018-12-18 23:06:03,160 INFO [PEWorker-14] procedure2.ProcedureExecutor:
> Initialized subprocedures=[{pid=151404, ppid=151104, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
> ...
> 2018-12-18 23:06:38,208 INFO [PEWorker-10] procedure.ServerCrashProcedure:
> Start pid=151632, state=RUNNABLE:SERVER_CRASH_START, hasLock=true;
> ServerCrashProcedure server=oldServer,17020,1545202098577, splitWal=true,
> meta=false
> ...
> 2018-12-18 23:06:41,953 WARN [RSProcedureDispatcher-pool4-t115]
> assignment.RegionRemoteProcedureBase: The remote operation pid=151404,
> ppid=151104, state=RUNNABLE, hasLock=false;
> org.apache.hadoop.hbase.mast
[jira] [Comment Edited] (HBASE-21623) ServerCrashProcedure can stomp on a RIT for a wrong server
[
https://issues.apache.org/jira/browse/HBASE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768632#comment-16768632
]
Sergey Shelukhin edited comment on HBASE-21623 at 2/14/19 7:24 PM:
---
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as follows (where each individual step looks safe from
lower-level races to me, given language-level sync)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
was (Author: sershe):
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as follows (where each individual step looks safe from
lower-level races to me, given region lock)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
> ServerCrashProcedure can stomp on a RIT for a wrong server
> --
>
> Key: HBASE-21623
> URL: https://issues.apache.org/jira/browse/HBASE-21623
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Attachments: HBASE-21623.patch
>
>
> A server died while some region was being opened on it; eventually the open
> failed, and the RIT procedure started retrying on a different server.
> However, by then SCP for the dying server had already obtained the region
> from the list of regions on the old server, and proceeded to overwrite
> whatever the RIT was doing with a new server.
> {noformat}
> 2018-12-18 23:06:03,160 INFO [PEWorker-14] procedure2.ProcedureExecutor:
> Initialized subprocedures=[{pid=151404, ppid=151104, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
> ...
> 2018-12-18 23:06:38,208 INFO [PEWorker-10] procedure.ServerCrashProcedure:
> Start pid=151632, state=RUNNABLE:SERVER_CRASH_START, hasLock=true;
> ServerCrashProcedure server=oldServer,17020,1545202098577, splitWal=true,
> meta=false
> ...
> 2018-12-18 23:06:41,953 WARN [RSProcedureDispatcher-pool4-t115]
> assignment.RegionRemoteProcedureBase: The remote operation pid=151404,
> ppid=151104, state=RUNNABLE, hasLock=false;
> org.apache.hadoop.hbase.master.assignment.OpenRegio
[jira] [Comment Edited] (HBASE-21623) ServerCrashProcedure can stomp on a RIT for a wrong server
[
https://issues.apache.org/jira/browse/HBASE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768632#comment-16768632
]
Sergey Shelukhin edited comment on HBASE-21623 at 2/14/19 7:24 PM:
---
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as follows (where each individual step looks safe from
lower-level races to me, given region lock)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
was (Author: sershe):
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as following (where each individual step looks safe from
lower-level races to me, given region lock)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
> ServerCrashProcedure can stomp on a RIT for a wrong server
> --
>
> Key: HBASE-21623
> URL: https://issues.apache.org/jira/browse/HBASE-21623
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Attachments: HBASE-21623.patch
>
>
> A server died while some region was being opened on it; eventually the open
> failed, and the RIT procedure started retrying on a different server.
> However, by then SCP for the dying server had already obtained the region
> from the list of regions on the old server, and proceeded to overwrite
> whatever the RIT was doing with a new server.
> {noformat}
> 2018-12-18 23:06:03,160 INFO [PEWorker-14] procedure2.ProcedureExecutor:
> Initialized subprocedures=[{pid=151404, ppid=151104, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
> ...
> 2018-12-18 23:06:38,208 INFO [PEWorker-10] procedure.ServerCrashProcedure:
> Start pid=151632, state=RUNNABLE:SERVER_CRASH_START, hasLock=true;
> ServerCrashProcedure server=oldServer,17020,1545202098577, splitWal=true,
> meta=false
> ...
> 2018-12-18 23:06:41,953 WARN [RSProcedureDispatcher-pool4-t115]
> assignment.RegionRemoteProcedureBase: The remote operation pid=151404,
> ppid=151104, state=RUNNABLE, hasLock=false;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProce
[jira] [Comment Edited] (HBASE-21623) ServerCrashProcedure can stomp on a RIT for a wrong server
[
https://issues.apache.org/jira/browse/HBASE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768632#comment-16768632
]
Sergey Shelukhin edited comment on HBASE-21623 at 2/14/19 7:23 PM:
---
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as following (where each individual step looks safe from
lower-level races to me, given region lock)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! (*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for (*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
was (Author: sershe):
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as following (where each individual step looks safe from
lower-level races to me, given region lock.
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! (*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for (*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
> ServerCrashProcedure can stomp on a RIT for a wrong server
> --
>
> Key: HBASE-21623
> URL: https://issues.apache.org/jira/browse/HBASE-21623
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Attachments: HBASE-21623.patch
>
>
> A server died while some region was being opened on it; eventually the open
> failed, and the RIT procedure started retrying on a different server.
> However, by then SCP for the dying server had already obtained the region
> from the list of regions on the old server, and proceeded to overwrite
> whatever the RIT was doing with a new server.
> {noformat}
> 2018-12-18 23:06:03,160 INFO [PEWorker-14] procedure2.ProcedureExecutor:
> Initialized subprocedures=[{pid=151404, ppid=151104, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
> ...
> 2018-12-18 23:06:38,208 INFO [PEWorker-10] procedure.ServerCrashProcedure:
> Start pid=151632, state=RUNNABLE:SERVER_CRASH_START, hasLock=true;
> ServerCrashProcedure server=oldServer,17020,1545202098577, splitWal=true,
> meta=false
> ...
> 2018-12-18 23:06:41,953 WARN [RSProcedureDispatcher-pool4-t115]
> assignment.RegionRemoteProcedureBase: The remote operation pid=151404,
> ppid=151104, state=RUNNABLE, hasLock=false;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProcedu
[jira] [Comment Edited] (HBASE-21623) ServerCrashProcedure can stomp on a RIT for a wrong server
[
https://issues.apache.org/jira/browse/HBASE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768632#comment-16768632
]
Sergey Shelukhin edited comment on HBASE-21623 at 2/14/19 7:23 PM:
---
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as following (where each individual step looks safe from
lower-level races to me, given region lock)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! \(*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for \(*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
was (Author: sershe):
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as following (where each individual step looks safe from
lower-level races to me, given region lock)
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! (*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for (*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
> ServerCrashProcedure can stomp on a RIT for a wrong server
> --
>
> Key: HBASE-21623
> URL: https://issues.apache.org/jira/browse/HBASE-21623
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Attachments: HBASE-21623.patch
>
>
> A server died while some region was being opened on it; eventually the open
> failed, and the RIT procedure started retrying on a different server.
> However, by then SCP for the dying server had already obtained the region
> from the list of regions on the old server, and proceeded to overwrite
> whatever the RIT was doing with a new server.
> {noformat}
> 2018-12-18 23:06:03,160 INFO [PEWorker-14] procedure2.ProcedureExecutor:
> Initialized subprocedures=[{pid=151404, ppid=151104, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
> ...
> 2018-12-18 23:06:38,208 INFO [PEWorker-10] procedure.ServerCrashProcedure:
> Start pid=151632, state=RUNNABLE:SERVER_CRASH_START, hasLock=true;
> ServerCrashProcedure server=oldServer,17020,1545202098577, splitWal=true,
> meta=false
> ...
> 2018-12-18 23:06:41,953 WARN [RSProcedureDispatcher-pool4-t115]
> assignment.RegionRemoteProcedureBase: The remote operation pid=151404,
> ppid=151104, state=RUNNABLE, hasLock=false;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProce
[jira] [Commented] (HBASE-21623) ServerCrashProcedure can stomp on a RIT for a wrong server
[
https://issues.apache.org/jira/browse/HBASE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768632#comment-16768632
]
Sergey Shelukhin commented on HBASE-21623:
--
Do you mean the language-level lock, or the HBase-level region lock?
The rit retried on a different server and so the fact that the region was at
one time opening on the crashed server was irrelevant at that point. SCP
doesn't appear to care for the HBase-level locks when it makes the decision to
replace (and it couldn't, cause whether it is updating the right or wrong RIT,
the latter would still be holding that, so the situation is not different).
The language-level lock protects individual procedure assignments from racing -
assuming every piece of code under it does correct checks;auditing them all is
out of the scope of this issue, I was assuming you see some specific bug with
that.
The race proceeds as following (where each individual step looks safe from
lower-level races to me, given region lock.
RIT: OPENING r1 on server1.
Server1: (silence)
SCP: server1 crashed, what's on server1? looks like r1
RIT: open failed, OPENING r1 on server2 now
Server2: opening...
SCP: looks like a RIT on r1; hey RIT for r1, your server crashed! (*)
RIT: oh well, OPENING r1 on server3 now
Which in this case also leads to
Server3: opening...
Server2: hey I opened r1!
RIT: who cares, it's on server3 now (as a side note, I'm adding a RS kill here
in a separate JIRA, ignoring this is not safe)
Server3: hey I (also) opened r1!
The fix is for (*) to check which server has crashed. I don't think SCP can
list regions and notify atomically without major changes, because they are
separate state machine states.
> ServerCrashProcedure can stomp on a RIT for a wrong server
> --
>
> Key: HBASE-21623
> URL: https://issues.apache.org/jira/browse/HBASE-21623
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Attachments: HBASE-21623.patch
>
>
> A server died while some region was being opened on it; eventually the open
> failed, and the RIT procedure started retrying on a different server.
> However, by then SCP for the dying server had already obtained the region
> from the list of regions on the old server, and proceeded to overwrite
> whatever the RIT was doing with a new server.
> {noformat}
> 2018-12-18 23:06:03,160 INFO [PEWorker-14] procedure2.ProcedureExecutor:
> Initialized subprocedures=[{pid=151404, ppid=151104, state=RUNNABLE,
> hasLock=false; org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure}]
> ...
> 2018-12-18 23:06:38,208 INFO [PEWorker-10] procedure.ServerCrashProcedure:
> Start pid=151632, state=RUNNABLE:SERVER_CRASH_START, hasLock=true;
> ServerCrashProcedure server=oldServer,17020,1545202098577, splitWal=true,
> meta=false
> ...
> 2018-12-18 23:06:41,953 WARN [RSProcedureDispatcher-pool4-t115]
> assignment.RegionRemoteProcedureBase: The remote operation pid=151404,
> ppid=151104, state=RUNNABLE, hasLock=false;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure for region
> {ENCODED => region1, ... } to server oldServer,17020,1545202098577 failed
> org.apache.hadoop.hbase.regionserver.RegionServerAbortedException:
> org.apache.hadoop.hbase.regionserver.RegionServerAbortedException: Server
> oldServer,17020,1545202098577 aborting
> 2018-12-18 23:06:42,485 INFO [PEWorker-5] procedure2.ProcedureExecutor:
> Finished subprocedure(s) of pid=151104, ppid=150875,
> state=RUNNABLE:REGION_STATE_TRANSITION_CONFIRM_OPENED, hasLock=true;
> TransitRegionStateProcedure table=t1, region=region1, ASSIGN; resume parent
> processing.
> 2018-12-18 23:06:42,485 INFO [PEWorker-13]
> assignment.TransitRegionStateProcedure: Retry=1 of max=2147483647;
> pid=151104, ppid=150875,
> state=RUNNABLE:REGION_STATE_TRANSITION_CONFIRM_OPENED, hasLock=true;
> TransitRegionStateProcedure table=t1, region=region1, ASSIGN; rit=OPENING,
> location=oldServer,17020,1545202098577
> 2018-12-18 23:06:42,500 INFO [PEWorker-13]
> assignment.TransitRegionStateProcedure: Starting pid=151104, ppid=150875,
> state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE, hasLock=true;
> TransitRegionStateProcedure table=t1, region=region1, ASSIGN; rit=OPENING,
> location=null; forceNewPlan=true, retain=false
> 2018-12-18 23:06:42,657 INFO [PEWorker-2] assignment.RegionStateStore:
> pid=151104 updating hbase:meta row=region1, regionState=OPENING,
> regionLocation=newServer,17020,1545202111238
> ...
> 2018-12-18 23:06:43,094 INFO [PEWorker-4] procedure.ServerCrashProcedure:
> pid=151632, state=RUNNABLE:SERVER_CRASH_ASSIGN, hasLock=true;
> ServerCrashProcedure
[jira] [Comment Edited] (HBASE-21844) Master could get stuck in initializing state while waiting for meta
[ https://issues.apache.org/jira/browse/HBASE-21844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764706#comment-16764706 ] Bahram Chehrazy edited comment on HBASE-21844 at 2/14/19 7:16 PM: -- Also, related to the WAL corruption, I've found several errors like this. This happened after some transient HDFS issues which lead to several servers crashing. It seems that there is a race condition between two servers trying to create the same log file: 2019-02-06 07:58:30,943 WARN [WALProcedureStoreSyncThread] wal.WALProcedureStore: *failed to create log file with id=116* org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.AlreadyBeingCreatedException): Failed to CREATE_FILE /wdphbase/bachehra_Hbase-ingestion-test_30RS_300R-100k-compaction-2/MasterProcWALs/pv2-0116.log for DFSClient_NONMAPREDUCE_1940839211_1 on *xx.xxx.xxx.xxx* because this file lease is currently owned by DFSClient_NONMAPREDUCE_1385418312_1 on *yy.yyy.yyy.yyy* at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.recoverLeaseInternal(FSNamesystem.java:2583) at org.apache.hadoop.hdfs.server.namenode.FSDirWriteFileOp.startFile(FSDirWriteFileOp.java:357) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInt(FSNamesystem.java:2431) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileUncheckedMount(FSNamesystem.java:2352) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFile(FSNamesystem.java:2339) at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.create(NameNodeRpcServer.java:748) at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.create(ClientNamenodeProtocolServerSideTranslatorPB.java:421) at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:503) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:989) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:871) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:817) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1893) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2621) at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1507) at org.apache.hadoop.ipc.Client.call(Client.java:1453) at org.apache.hadoop.ipc.Client.call(Client.java:1363) at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:227) at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:116) at com.sun.proxy.$Proxy19.create(Unknown Source) at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.create(ClientNamenodeProtocolTranslatorPB.java:297) at sun.reflect.GeneratedMethodAccessor99.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:422) at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:165) at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:157) at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95) at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:359) at com.sun.proxy.$Proxy20.create(Unknown Source) at sun.reflect.GeneratedMethodAccessor99.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:372) at com.sun.proxy.$Proxy21.create(Unknown Source) at org.apache.hadoop.hdfs.DFSOutputStream.newStreamForCreate(DFSOutputStream.java:267) at org.apache.hadoop.hdfs.DFSClient.create(DFSClient.java:1246) at org.apache.hadoop.hdfs.DFSClient.create(DFSClient.java:1188) at org.apache.hadoop.hdfs.DistributedFileSystem$8.doCall(DistributedFileSystem.java:480) at org.apache.hadoop.hdfs.DistributedFileSystem$8.doCall(DistributedFileSystem.java:477) at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81) at org.apache.hadoop.hdfs.DistributedFileSystem.create(DistributedFileSystem.java:491) at org.apache.hadoop.hdfs.DistributedFileSystem.create(DistributedFileSystem.java:418) at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:1067) at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:1048) at org.apache.hadoop.fs.FileSyst
[jira] [Commented] (HBASE-21894) Master doesn't update the meta state as soon as the meta server dies
[ https://issues.apache.org/jira/browse/HBASE-21894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768624#comment-16768624 ] Sergey Shelukhin commented on HBASE-21894: -- Test failure for Meta-Locator looks related. "If this server carries any system region, mark them as CLOSING before starting the procedure. " - who does it for non-system regions? Looks good otherwise. > Master doesn't update the meta state as soon as the meta server dies > > > Key: HBASE-21894 > URL: https://issues.apache.org/jira/browse/HBASE-21894 > Project: HBase > Issue Type: Bug > Components: master, meta >Affects Versions: 3.0.0 >Reporter: Bahram Chehrazy >Assignee: Bahram Chehrazy >Priority: Major > Attachments: Master-to-update-meta-state-on-ZK-asap.patch, > Update-master-in-memory-state-of-meta-asap.patch > > > > When the meta server dies, Master moves that server to the deadServers list > and submits a SCP, but it doesn't change the Meta region state (to CLOSING, > CLOSED or OFFLINE) until after SCP finishes. Only at that time the meta > region state changes from OPEN to OPENING, and then quickly back to OPEN. > > This could cause problems if some procedures try to update meta while master > is recovering the meta region, or even worse, if the master also dies in the > mean time. Other potential problem include servers trying to update the meta > which it's down, causing them to abort after several retries. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21883) Enhancements to Major Compaction tool from HBASE-19528
[ https://issues.apache.org/jira/browse/HBASE-21883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768606#comment-16768606 ] Thiruvel Thirumoolan commented on HBASE-21883: -- Unit test failures are unrelated to the patch. > Enhancements to Major Compaction tool from HBASE-19528 > -- > > Key: HBASE-21883 > URL: https://issues.apache.org/jira/browse/HBASE-21883 > Project: HBase > Issue Type: Improvement > Components: Client, Compaction, tooling >Affects Versions: 1.5.0 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Minor > Fix For: 1.5.1 > > Attachments: HBASE-21883.branch-1.001.patch, > HBASE-21883.branch-1.002.patch > > > I would like to add new compaction tools based on [~churromorales]'s tool at > HBASE-19528. > We internally have tools that pick and compact regions based on multiple > criteria. Since Rahul already has a version in community, we would like to > build on top of it instead of pushing yet another tool. > With this jira, I would like to add a tool which looks at regions beyond TTL > and compacts them in a rsgroup. We have time series data and those regions > will become dead after a while, so we compact those regions to save disk > space. We also merge those empty regions to reduce load, but that tool comes > later. > Will prep a patch for 2.x once 1.5 gets in. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21902) TestCompactionWithCoprocessor doesn't invoke coprocessor logic
david zhang created HBASE-21902: --- Summary: TestCompactionWithCoprocessor doesn't invoke coprocessor logic Key: HBASE-21902 URL: https://issues.apache.org/jira/browse/HBASE-21902 Project: HBase Issue Type: Test Components: test Affects Versions: 2.0.4 Reporter: david zhang Attachments: hbase-test.patch TestCompactionWithCoprocessor is designed to invoke NoOpScanPolicyObserver which implements default behavior. in reality NoOpScanPolicyObserver isn't instantiated, TestCompactionWithCoprocessor runs/passes trivially, without increasing test coverage beyond TestCompaction. See patch which passes TestCompactionWithCoprocessor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21505) Several inconsistencies on information reported for Replication Sources by hbase shell status 'replication' command.
[
https://issues.apache.org/jira/browse/HBASE-21505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768595#comment-16768595
]
Hadoop QA commented on HBASE-21505:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
24s{color} | {color:blue} hbase-hadoop2-compat in master has 18 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
35s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch passed checkstyle in hbase-protocol-shaded
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch passed checkstyle in hbase-hadoop-compat
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} The patch passed checkstyle in hbase-hadoop2-compat
{color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
36s{color} | {color:red} hbase-client: The patch generated 2 new + 185
unchanged - 0 fixed = 187 total (was 185) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} hbase-server: The patch generated 0 new + 84
unchanged - 3 fixed = 84 total (was 87) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch passed checkstyle in hbase-shell {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
8s{color} | {color:red} The patch generated 8 new + 434 unchanged - 17 fixed =
442 total (was 451) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 3s{color} | {color:orange} The patch generated 3 new + 752 unchanged - 2
fixed = 755 total (was 754) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 41s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
2m 28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color}
[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection
[
https://issues.apache.org/jira/browse/HBASE-21717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768567#comment-16768567
]
Hadoop QA commented on HBASE-21717:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
1s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 62 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21512 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
18s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
47s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
13s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
15s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
13s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
7s{color} | {color:green} HBASE-21512 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
44s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 39s{color}
| {color:red} hbase-client generated 6 new + 85 unchanged - 6 fixed = 91 total
(was 91) {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 51s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} hbase-client: The patch generated 0 new + 97
unchanged - 32 fixed = 97 total (was 129) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
21s{color} | {color:red} hbase-server: The patch generated 14 new + 796
unchanged - 48 fixed = 810 total (was 844) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s{color} | {color:green} The patch passed checkstyle in hbase-mapreduce
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
28s{color} | {color:green} The patch passed checkstyle in hbase-thrift {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} hbase-backup: The patch generated 0 new + 0
unchanged - 1 fixed = 0 total (was 1) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s{color} | {color:green} hbase-rest: The patch generated 0 new + 76 unchanged
- 58 fixed = 76 total (was 134) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 2m
1s{color} | {color:red} patch has 10 errors when building our shaded downstream
artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 38s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
16s{color} | {color:green} hbase-clien
[GitHub] asfgit commented on issue #16: Dummy change in pom.xml for PR verification
asfgit commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463720822 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/6/ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification
petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463720654 retest build This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] asfgit commented on issue #16: Dummy change in pom.xml for PR verification
asfgit commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463719391 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/5/ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification
petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463719234 retest build This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] asfgit commented on issue #16: Dummy change in pom.xml for PR verification
asfgit commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463718575 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/4/ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-19889) Revert Workaround: Purge User API building from branch-2 so can make a beta-1
[
https://issues.apache.org/jira/browse/HBASE-19889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768555#comment-16768555
]
Hudson commented on HBASE-19889:
Results for branch branch-2.0
[build #1348 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Revert Workaround: Purge User API building from branch-2 so can make a beta-1
> -
>
> Key: HBASE-19889
> URL: https://issues.apache.org/jira/browse/HBASE-19889
> Project: HBase
> Issue Type: Sub-task
> Components: website
>Reporter: stack
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: hbase-19889.branch-2.0.001.patch,
> hbase-19889.branch-2.0.002.patch, hbase-19889.branch-2.1.001.patch
>
>
> Root fix looks to be -HBASE-19780-
> Let me try it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification
petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463718257 retest build This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-21900) Infinite loop in AsyncMetaRegionLocator if we can not get the location for meta
[
https://issues.apache.org/jira/browse/HBASE-21900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768554#comment-16768554
]
Hudson commented on HBASE-21900:
Results for branch branch-2.0
[build #1348 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1348//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Infinite loop in AsyncMetaRegionLocator if we can not get the location for
> meta
> ---
>
> Key: HBASE-21900
> URL: https://issues.apache.org/jira/browse/HBASE-21900
> Project: HBase
> Issue Type: Bug
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21900.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification
petersomogyi commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463716561 retest build This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-21872) Clean up getBytes() calls without charsets provided
[
https://issues.apache.org/jira/browse/HBASE-21872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-21872:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> Clean up getBytes() calls without charsets provided
> ---
>
> Key: HBASE-21872
> URL: https://issues.apache.org/jira/browse/HBASE-21872
> Project: HBase
> Issue Type: Task
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Trivial
> Fix For: 3.0.0
>
> Attachments: HBASE-21782.001.patch, HBASE-21782.002.patch,
> HBASE-21782.003.patch, HBASE-21872.004.patch
>
>
> As we saw over in HBASE-21201, the use of {{String.getBytes()}} without a
> Charset can result is some compiler warnings. Let's just get rid of these
> calls. There are only a handful anymore in master.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] asfgit commented on issue #16: Dummy change in pom.xml for PR verification
asfgit commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463713176 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/3/ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] asfgit commented on issue #16: Dummy change in pom.xml for PR verification
asfgit commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463710491 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/2/ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] asfgit commented on issue #16: Dummy change in pom.xml for PR verification
asfgit commented on issue #16: Dummy change in pom.xml for PR verification URL: https://github.com/apache/hbase-connectors/pull/16#issuecomment-463708767 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/1/ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work started] (HBASE-21901) update branch-1.2 ref guide for 1.2.11 release
[ https://issues.apache.org/jira/browse/HBASE-21901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-21901 started by Sean Busbey. --- > update branch-1.2 ref guide for 1.2.11 release > -- > > Key: HBASE-21901 > URL: https://issues.apache.org/jira/browse/HBASE-21901 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 1.2.11 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 1.2.11 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19889) Revert Workaround: Purge User API building from branch-2 so can make a beta-1
[
https://issues.apache.org/jira/browse/HBASE-19889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768500#comment-16768500
]
Hudson commented on HBASE-19889:
Results for branch branch-2.1
[build #865 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/865/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/865//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/865//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/865//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Revert Workaround: Purge User API building from branch-2 so can make a beta-1
> -
>
> Key: HBASE-19889
> URL: https://issues.apache.org/jira/browse/HBASE-19889
> Project: HBase
> Issue Type: Sub-task
> Components: website
>Reporter: stack
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: hbase-19889.branch-2.0.001.patch,
> hbase-19889.branch-2.0.002.patch, hbase-19889.branch-2.1.001.patch
>
>
> Root fix looks to be -HBASE-19780-
> Let me try it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
