[jira] [Updated] (HBASE-15829) hbase.client.retries.number has different meanings in branch-1 and master
[
https://issues.apache.org/jira/browse/HBASE-15829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang updated HBASE-15829:
---
Fix Version/s: 2.0.0
Status: Patch Available (was: Open)
> hbase.client.retries.number has different meanings in branch-1 and master
> -
>
> Key: HBASE-15829
> URL: https://issues.apache.org/jira/browse/HBASE-15829
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15829.patch
>
>
> The comment of hbase.client.retries.number is:
> {code}
> /**
>* Parameter name for maximum retries, used as maximum for all retryable
>* operations such as fetching of the root region from root region server,
>* getting a cell's value, starting a row update, etc.
>*/
> public static final String HBASE_CLIENT_RETRIES_NUMBER =
> "hbase.client.retries.number";
> {code}
> In branch-1, the max attempts number equals with hbase.client.retries.number.
> But in master, the max attempts number equals with
> hbase.client.retries.number + 1.
> For RpcRetryingCaller.
> {code}
> this.retries = retries; // branch-1
> {code}
> {code}
> this.maxAttempts = retries + 1; // master
> {code}
> For AsyncProcess:
> {code}
> this.numTries = conf.getInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER,
> HConstants.DEFAULT_HBASE_CLIENT_RETRIES_NUMBER); // branch-1
> {code}
> {code}
> // how many times we could try in total, one more than retry number
> this.numTries = conf.getInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER,
> HConstants.DEFAULT_HBASE_CLIENT_RETRIES_NUMBER) + 1; // master
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15829) hbase.client.retries.number has different meanings in branch-1 and master
[
https://issues.apache.org/jira/browse/HBASE-15829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang updated HBASE-15829:
---
Attachment: HBASE-15829.patch
Attach a patch for master which keep hbase.client.retries.number meanings same
with branch-1.
> hbase.client.retries.number has different meanings in branch-1 and master
> -
>
> Key: HBASE-15829
> URL: https://issues.apache.org/jira/browse/HBASE-15829
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Priority: Minor
> Attachments: HBASE-15829.patch
>
>
> The comment of hbase.client.retries.number is:
> {code}
> /**
>* Parameter name for maximum retries, used as maximum for all retryable
>* operations such as fetching of the root region from root region server,
>* getting a cell's value, starting a row update, etc.
>*/
> public static final String HBASE_CLIENT_RETRIES_NUMBER =
> "hbase.client.retries.number";
> {code}
> In branch-1, the max attempts number equals with hbase.client.retries.number.
> But in master, the max attempts number equals with
> hbase.client.retries.number + 1.
> For RpcRetryingCaller.
> {code}
> this.retries = retries; // branch-1
> {code}
> {code}
> this.maxAttempts = retries + 1; // master
> {code}
> For AsyncProcess:
> {code}
> this.numTries = conf.getInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER,
> HConstants.DEFAULT_HBASE_CLIENT_RETRIES_NUMBER); // branch-1
> {code}
> {code}
> // how many times we could try in total, one more than retry number
> this.numTries = conf.getInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER,
> HConstants.DEFAULT_HBASE_CLIENT_RETRIES_NUMBER) + 1; // master
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15829) hbase.client.retries.number has different meanings in branch-1 and master
Guanghao Zhang created HBASE-15829:
--
Summary: hbase.client.retries.number has different meanings in
branch-1 and master
Key: HBASE-15829
URL: https://issues.apache.org/jira/browse/HBASE-15829
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0
Reporter: Guanghao Zhang
Priority: Minor
The comment of hbase.client.retries.number is:
{code}
/**
* Parameter name for maximum retries, used as maximum for all retryable
* operations such as fetching of the root region from root region server,
* getting a cell's value, starting a row update, etc.
*/
public static final String HBASE_CLIENT_RETRIES_NUMBER =
"hbase.client.retries.number";
{code}
In branch-1, the max attempts number equals with hbase.client.retries.number.
But in master, the max attempts number equals with hbase.client.retries.number
+ 1.
For RpcRetryingCaller.
{code}
this.retries = retries; // branch-1
{code}
{code}
this.maxAttempts = retries + 1; // master
{code}
For AsyncProcess:
{code}
this.numTries = conf.getInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER,
HConstants.DEFAULT_HBASE_CLIENT_RETRIES_NUMBER); // branch-1
{code}
{code}
// how many times we could try in total, one more than retry number
this.numTries = conf.getInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER,
HConstants.DEFAULT_HBASE_CLIENT_RETRIES_NUMBER) + 1; // master
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry
[
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283426#comment-15283426
]
Guanghao Zhang commented on HBASE-15615:
branch-1-v3.patch is same with master-v5.patch. It can apply to branch-1.1,
branch-1.2 and branch-1.3.
> Wrong sleep time when RegionServerCallable need retry
> -
>
> Key: HBASE-15615
> URL: https://issues.apache.org/jira/browse/HBASE-15615
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 1.2.0, 1.3.0, 0.98.19
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 1.3.0
>
> Attachments: HBASE-15615-branch-0.98.patch,
> HBASE-15615-branch-1-v3.patch, HBASE-15615-branch-1.0-v2.patch,
> HBASE-15615-branch-1.1-v2.patch, HBASE-15615-branch-1.1-v2.patch,
> HBASE-15615-branch-1.patch, HBASE-15615-v1.patch, HBASE-15615-v1.patch,
> HBASE-15615-v2.patch, HBASE-15615-v2.patch, HBASE-15615-v3.patch,
> HBASE-15615-v4.patch, HBASE-15615-v5.patch, HBASE-15615.patch
>
>
> In RpcRetryingCallerImpl, it get pause time by expectedSleep =
> callable.sleep(pause, tries + 1); And in RegionServerCallable, it get pasue
> time by sleep = ConnectionUtils.getPauseTime(pause, tries + 1). So tries will
> be bumped up twice. And the pasue time is 3 * hbase.client.pause when tries
> is 0.
> RETRY_BACKOFF = {1, 2, 3, 5, 10, 20, 40, 100, 100, 100, 100, 200, 200}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283427#comment-15283427 ] Mikhail Antonov commented on HBASE-15811: - Thanks [~rfarrjr] and [~stack]! > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry
[
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang updated HBASE-15615:
---
Attachment: HBASE-15615-branch-1-v3.patch
> Wrong sleep time when RegionServerCallable need retry
> -
>
> Key: HBASE-15615
> URL: https://issues.apache.org/jira/browse/HBASE-15615
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 1.2.0, 1.3.0, 0.98.19
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 1.3.0
>
> Attachments: HBASE-15615-branch-0.98.patch,
> HBASE-15615-branch-1-v3.patch, HBASE-15615-branch-1.0-v2.patch,
> HBASE-15615-branch-1.1-v2.patch, HBASE-15615-branch-1.1-v2.patch,
> HBASE-15615-branch-1.patch, HBASE-15615-v1.patch, HBASE-15615-v1.patch,
> HBASE-15615-v2.patch, HBASE-15615-v2.patch, HBASE-15615-v3.patch,
> HBASE-15615-v4.patch, HBASE-15615-v5.patch, HBASE-15615.patch
>
>
> In RpcRetryingCallerImpl, it get pause time by expectedSleep =
> callable.sleep(pause, tries + 1); And in RegionServerCallable, it get pasue
> time by sleep = ConnectionUtils.getPauseTime(pause, tries + 1). So tries will
> be bumped up twice. And the pasue time is 3 * hbase.client.pause when tries
> is 0.
> RETRY_BACKOFF = {1, 2, 3, 5, 10, 20, 40, 100, 100, 100, 100, 200, 200}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15790) Force "hbase" ownership on bulkload
[
https://issues.apache.org/jira/browse/HBASE-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283417#comment-15283417
]
Hadoop QA commented on HBASE-15790:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
1s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
49s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 43s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 106m 14s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 137m 54s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803994/HBASE-15790-v1.patch |
| JIRA Issue | HBASE-15790 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry
[
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283410#comment-15283410
]
Guanghao Zhang commented on HBASE-15615:
Attach a v5 patch. Add a ut to test sleep method of RegionServerCallable,
RegionAdminServiceCallable and MasterCallable. Meanwhile, I add a config for
SleepCoprocessor to reduce the sleep time of ut.
> Wrong sleep time when RegionServerCallable need retry
> -
>
> Key: HBASE-15615
> URL: https://issues.apache.org/jira/browse/HBASE-15615
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 1.2.0, 1.3.0, 0.98.19
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 1.3.0
>
> Attachments: HBASE-15615-branch-0.98.patch,
> HBASE-15615-branch-1.0-v2.patch, HBASE-15615-branch-1.1-v2.patch,
> HBASE-15615-branch-1.1-v2.patch, HBASE-15615-branch-1.patch,
> HBASE-15615-v1.patch, HBASE-15615-v1.patch, HBASE-15615-v2.patch,
> HBASE-15615-v2.patch, HBASE-15615-v3.patch, HBASE-15615-v4.patch,
> HBASE-15615-v5.patch, HBASE-15615.patch
>
>
> In RpcRetryingCallerImpl, it get pause time by expectedSleep =
> callable.sleep(pause, tries + 1); And in RegionServerCallable, it get pasue
> time by sleep = ConnectionUtils.getPauseTime(pause, tries + 1). So tries will
> be bumped up twice. And the pasue time is 3 * hbase.client.pause when tries
> is 0.
> RETRY_BACKOFF = {1, 2, 3, 5, 10, 20, 40, 100, 100, 100, 100, 200, 200}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry
[
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang updated HBASE-15615:
---
Attachment: HBASE-15615-v5.patch
> Wrong sleep time when RegionServerCallable need retry
> -
>
> Key: HBASE-15615
> URL: https://issues.apache.org/jira/browse/HBASE-15615
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.0.0, 2.0.0, 1.1.0, 1.2.0, 1.3.0, 0.98.19
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 1.3.0
>
> Attachments: HBASE-15615-branch-0.98.patch,
> HBASE-15615-branch-1.0-v2.patch, HBASE-15615-branch-1.1-v2.patch,
> HBASE-15615-branch-1.1-v2.patch, HBASE-15615-branch-1.patch,
> HBASE-15615-v1.patch, HBASE-15615-v1.patch, HBASE-15615-v2.patch,
> HBASE-15615-v2.patch, HBASE-15615-v3.patch, HBASE-15615-v4.patch,
> HBASE-15615-v5.patch, HBASE-15615.patch
>
>
> In RpcRetryingCallerImpl, it get pause time by expectedSleep =
> callable.sleep(pause, tries + 1); And in RegionServerCallable, it get pasue
> time by sleep = ConnectionUtils.getPauseTime(pause, tries + 1). So tries will
> be bumped up twice. And the pasue time is 3 * hbase.client.pause when tries
> is 0.
> RETRY_BACKOFF = {1, 2, 3, 5, 10, 20, 40, 100, 100, 100, 100, 200, 200}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283404#comment-15283404
]
Hudson commented on HBASE-13532:
FAILURE: Integrated in HBase-Trunk_matrix #918 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/918/])
HBASE-13532 Make UnknownScannerException less scary by giving more
(matteo.bertozzi: rev 60e19f60a9767db6b145cf9884d2295412baffe0)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
>
[jira] [Commented] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283403#comment-15283403 ] Hudson commented on HBASE-15811: FAILURE: Integrated in HBase-Trunk_matrix #918 (See [https://builds.apache.org/job/HBase-Trunk_matrix/918/]) HBASE-15811 Batch Get after batch Put does not fetch all Cells We were (stack: rev 6904430a3d2bd87190b5f5d51a85d929684caae1) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15725) make_patch.sh should add the branch name when -b is passed.
[ https://issues.apache.org/jira/browse/HBASE-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283402#comment-15283402 ] Hudson commented on HBASE-15725: FAILURE: Integrated in HBase-Trunk_matrix #918 (See [https://builds.apache.org/job/HBase-Trunk_matrix/918/]) HBASE-15725 make_patch.sh should add the branch name when -b is passed. (eclark: rev 0e281e1929fbd8332001ef5a2a44091d790a67bb) * dev-support/make_patch.sh > make_patch.sh should add the branch name when -b is passed. > --- > > Key: HBASE-15725 > URL: https://issues.apache.org/jira/browse/HBASE-15725 > Project: HBase > Issue Type: Bug > Components: tooling >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0 > > Attachments: HBASE-15725-v4.patch, HBASE-15725-v5.patch > > > When using something other than master as the base branch we should default > to adding the branch name to the patch file name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283397#comment-15283397 ] Hudson commented on HBASE-15811: SUCCESS: Integrated in HBase-1.2-IT #507 (See [https://builds.apache.org/job/HBase-1.2-IT/507/]) HBASE-15811 Batch Get after batch Put does not fetch all Cells We were (stack: rev df634737cc019a6ca088b640f23b4acb96331043) * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283393#comment-15283393
]
Ted Yu commented on HBASE-15827:
Got some test failures on the backport to branch-1.1 :
{code}
testRegionHole(org.apache.hadoop.hbase.util.TestHBaseFsck) Time elapsed: 5.866
sec <<< FAILURE!
java.lang.AssertionError: expected:<[HOLE_IN_REGION_CHAIN]> but
was:<[HOLE_IN_REGION_CHAIN, EXPIRED_TABLE_LOCK]>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.assertErrors(HbckTestingUtil.java:99)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testRegionHole(TestHBaseFsck.java:1189)
testNotInMetaOrDeployedHole(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
elapsed: 5.877 sec <<< FAILURE!
java.lang.AssertionError: expected:<[NOT_IN_META_OR_DEPLOYED,
HOLE_IN_REGION_CHAIN]> but was:<[NOT_IN_META_OR_DEPLOYED, HOLE_IN_REGION_CHAIN,
EXPIRED_TABLE_LOCK]>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.assertErrors(HbckTestingUtil.java:99)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testNotInMetaOrDeployedHole(TestHBaseFsck.java:1307)
testMissingFirstRegion(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
elapsed: 5.869 sec <<< FAILURE!
java.lang.AssertionError: expected:<[FIRST_REGION_STARTKEY_NOT_EMPTY]> but
was:<[FIRST_REGION_STARTKEY_NOT_EMPTY, EXPIRED_TABLE_LOCK]>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.assertErrors(HbckTestingUtil.java:99)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testMissingFirstRegion(TestHBaseFsck.java:1867)
{code}
Will investigate later.
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.2.2
>
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283390#comment-15283390 ] Hudson commented on HBASE-15811: SUCCESS: Integrated in HBase-1.3-IT #660 (See [https://builds.apache.org/job/HBase-1.3-IT/660/]) HBASE-15811 Batch Get after batch Put does not fetch all Cells We were (stack: rev 09934af5c7e9c9d5bd46b20db8ce17f7b96aee58) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15125) HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary
[ https://issues.apache.org/jira/browse/HBASE-15125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283388#comment-15283388 ] Hudson commented on HBASE-15125: FAILURE: Integrated in HBase-1.2 #624 (See [https://builds.apache.org/job/HBase-1.2/624/]) Backport HBASE-15125 HBaseFsck's adoptHdfsOrphan function creates region (tedyu: rev f778736b658b28b24ce7bb7428ab3b268d742765) * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java > HBaseFsck's adoptHdfsOrphan function creates region with wrong end key > boundary > --- > > Key: HBASE-15125 > URL: https://issues.apache.org/jira/browse/HBASE-15125 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 2.0.0 >Reporter: chenrongwei >Assignee: chenrongwei > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15125-V001.patch, HBASE-15125-v001-for-branch-1, > HBASE-15125-v002.patch, HBASE-15125-v003.patch, HBASE-15125-v004.patch, > HBASE-15125-v004.patch, HBASE-15125-v005.patch > > > There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this > function will create a region,which want to cover all the orphan regions.But > the end key of this new region was set incorrectly.Correct region's boundary > should be [startKey,endKey),but this function create a region with boundary > of [startKey,endKey],this bug will leads to scan operation omit some data. > I think we should create the region like bellow, > // create new region on hdfs. move data into place. > HRegionInfo hri = new HRegionInfo(template.getTableName(), > orphanRegionRange.getFirst(), > Bytes.add(orphanRegionRange.getSecond(), new byte[1])); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283387#comment-15283387
]
Hudson commented on HBASE-13532:
SUCCESS: Integrated in HBase-1.3 #696 (See
[https://builds.apache.org/job/HBase-1.3/696/])
HBASE-13532 Make UnknownScannerException less scary by giving more
(matteo.bertozzi: rev 71d45393867c83a055cba2fc0bc07eab79367d90)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
>
[jira] [Commented] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283389#comment-15283389
]
Hudson commented on HBASE-13532:
FAILURE: Integrated in HBase-1.2 #624 (See
[https://builds.apache.org/job/HBase-1.2/624/])
HBASE-13532 Make UnknownScannerException less scary by giving more
(matteo.bertozzi: rev aaa43631490874a6d7ec8afdcebd8608212c8f8c)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
>
[jira] [Updated] (HBASE-15790) Force "hbase" ownership on bulkload
[ https://issues.apache.org/jira/browse/HBASE-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15790: Status: Patch Available (was: Open) > Force "hbase" ownership on bulkload > --- > > Key: HBASE-15790 > URL: https://issues.apache.org/jira/browse/HBASE-15790 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.98.19, 1.1.4, 1.2.1, 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Attachments: HBASE-15790-v0.patch, HBASE-15790-v1.patch > > > When a user different than "hbase" bulkload files, in general we end up with > files owned by a user different than hbase. sometimes this causes problems > with hbase not be able to move files around archiving/deleting. > A simple solution is probably to change the ownership of the files to "hbase" > during bulkload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15790) Force "hbase" ownership on bulkload
[ https://issues.apache.org/jira/browse/HBASE-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15790: Attachment: HBASE-15790-v1.patch v1 simplifies it a bit, and removes the extra move that seems to be unnecessary > Force "hbase" ownership on bulkload > --- > > Key: HBASE-15790 > URL: https://issues.apache.org/jira/browse/HBASE-15790 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0, 1.2.1, 1.1.4, 0.98.19 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Attachments: HBASE-15790-v0.patch, HBASE-15790-v1.patch > > > When a user different than "hbase" bulkload files, in general we end up with > files owned by a user different than hbase. sometimes this causes problems > with hbase not be able to move files around archiving/deleting. > A simple solution is probably to change the ownership of the files to "hbase" > during bulkload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
[
https://issues.apache.org/jira/browse/HBASE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-15824:
-
Fix Version/s: (was: 1.1.5)
1.1.6
> LocalHBaseCluster gets bind exception in master info port
> -
>
> Key: HBASE-15824
> URL: https://issues.apache.org/jira/browse/HBASE-15824
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.2, 1.1.6
>
> Attachments: hbase-15824_v1.patch
>
>
> This is seen from Phoenix, since we already configure the ports in
> hbase-site.xml under hbase-server/src/test/resources.
> But this is also important for other {{hbase-testing-util}} consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15828) fix extant findbug
[ https://issues.apache.org/jira/browse/HBASE-15828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283358#comment-15283358 ] stack commented on HBASE-15828: --- I'll commit if you good w/ this [~mantonov] > fix extant findbug > -- > > Key: HBASE-15828 > URL: https://issues.apache.org/jira/browse/HBASE-15828 > Project: HBase > Issue Type: Bug > Components: findbugs >Affects Versions: 1.3.0 > Environment: > https://builds.apache.org/job/PreCommit-HBASE-Build/1889/artifact/patchprocess/branch-findbugs-hbase-client-warnings.html >Reporter: Mikhail Antonov >Assignee: stack > Fix For: 1.3.0 > > Attachments: HBASE-15828.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15828) fix extant findbug
[
https://issues.apache.org/jira/browse/HBASE-15828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283356#comment-15283356
]
Hadoop QA commented on HBASE-15828:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 26s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 17s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 55s
{color} | {color:red} hbase-client in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 19s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 16s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
37s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
14s {color} | {color:green} hbase-client generated 0 new + 0 unchanged - 1
fixed = 0 total (was 1) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 56s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 19m 36s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803988/HBASE-15828.patch |
| JIRA Issue | HBASE-15828 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / 6904430 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions |
[jira] [Updated] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15811: -- Resolution: Fixed Fix Version/s: (was: 0.98.19) Status: Resolved (was: Patch Available) Pushed to branch-1.1+ As it happens 0.98 doesn't have this issue after all after looking at the patch that was applied to branch 0.98 for HBASE-11403. > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283347#comment-15283347 ] stack commented on HBASE-15811: --- Thank you [~mantonov] > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 0.98.19, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15828) fix extant findbug
[ https://issues.apache.org/jira/browse/HBASE-15828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15828: -- Attachment: HBASE-15828.patch While the findbugs complaint is valid, in this particular case, I think folks will favor the HBase Future over the netty one -- the netty import will give them cause -- so I think the 'fix' here is suppressing findbugs complaint. [~jurmous] FYI > fix extant findbug > -- > > Key: HBASE-15828 > URL: https://issues.apache.org/jira/browse/HBASE-15828 > Project: HBase > Issue Type: Bug > Components: findbugs >Affects Versions: 1.3.0 > Environment: > https://builds.apache.org/job/PreCommit-HBASE-Build/1889/artifact/patchprocess/branch-findbugs-hbase-client-warnings.html >Reporter: Mikhail Antonov > Fix For: 1.3.0 > > Attachments: HBASE-15828.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15828) fix extant findbug
[ https://issues.apache.org/jira/browse/HBASE-15828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15828: -- Assignee: stack Status: Patch Available (was: Open) > fix extant findbug > -- > > Key: HBASE-15828 > URL: https://issues.apache.org/jira/browse/HBASE-15828 > Project: HBase > Issue Type: Bug > Components: findbugs >Affects Versions: 1.3.0 > Environment: > https://builds.apache.org/job/PreCommit-HBASE-Build/1889/artifact/patchprocess/branch-findbugs-hbase-client-warnings.html >Reporter: Mikhail Antonov >Assignee: stack > Fix For: 1.3.0 > > Attachments: HBASE-15828.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15823) Use call once for user util
[
https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283341#comment-15283341
]
Hadoop QA commented on HBASE-15823:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
1s {color} | {color:green} HBASE-14850 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 34s
{color} | {color:green} HBASE-14850 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 27s
{color} | {color:green} HBASE-14850 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 29s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 29s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 26s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 26s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
48s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 117m 11s
{color} | {color:green} root in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 21s
{color} | {color:red} Patch generated 5 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 144m 30s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803965/HBASE-15823-v2.HBASE-14850.patch
|
| JIRA Issue | HBASE-15823 |
| Optional Tests | asflicense cc unit compile |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | HBASE-14850 / e002553 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/1894/testReport/ |
| asflicense |
https://builds.apache.org/job/PreCommit-HBASE-Build/1894/artifact/patchprocess/patch-asflicense-problems.txt
|
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1894/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Use call once for user util
> ---
>
> Key: HBASE-15823
> URL: https://issues.apache.org/jira/browse/HBASE-15823
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15823-v1.patch, HBASE-15823-v2-HBASE-14850.patch,
> HBASE-15823-v2.HBASE-14850.patch, HBASE-15823.patch
>
>
> Faster less locking and more correct.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15828) fix extant findbug
Mikhail Antonov created HBASE-15828: --- Summary: fix extant findbug Key: HBASE-15828 URL: https://issues.apache.org/jira/browse/HBASE-15828 Project: HBase Issue Type: Bug Components: findbugs Affects Versions: 1.3.0 Environment: https://builds.apache.org/job/PreCommit-HBASE-Build/1889/artifact/patchprocess/branch-findbugs-hbase-client-warnings.html Reporter: Mikhail Antonov Fix For: 1.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283336#comment-15283336 ] Mikhail Antonov commented on HBASE-15780: - Let me open a jira to fix extant findbug as it gets annoying > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15816) Provide client with ability to set priority on Operations
[
https://issues.apache.org/jira/browse/HBASE-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283324#comment-15283324
]
Hadoop QA commented on HBASE-15816:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 20s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 5s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 57s
{color} | {color:red} hbase-client in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 13s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 13s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
47s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 57s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 100m 17s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 132m 18s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803956/HBASE-15816-v1.patch |
| JIRA Issue | HBASE-15816 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
|
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283322#comment-15283322
]
Hadoop QA commented on HBASE-15780:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 18s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 25s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 56s
{color} | {color:red} hbase-client in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 16s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 7s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 17s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
28s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
20s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 3m 27s
{color} | {color:red} hbase-common-jdk1.8.0 with JDK v1.8.0 generated 2 new + 0
unchanged - 0 fixed = 2 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 18s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 4m 34s
{color} | {color:red} hbase-common-jdk1.7.0_79 with JDK v1.7.0_79 generated 2
new + 5 unchanged - 0 fixed = 7 total (was 5) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 7s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 42s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 55s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 100m 35s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
39s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
|
[jira] [Commented] (HBASE-15125) HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary
[ https://issues.apache.org/jira/browse/HBASE-15125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283310#comment-15283310 ] Hudson commented on HBASE-15125: SUCCESS: Integrated in HBase-1.2-IT #506 (See [https://builds.apache.org/job/HBase-1.2-IT/506/]) Backport HBASE-15125 HBaseFsck's adoptHdfsOrphan function creates region (tedyu: rev f778736b658b28b24ce7bb7428ab3b268d742765) * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java > HBaseFsck's adoptHdfsOrphan function creates region with wrong end key > boundary > --- > > Key: HBASE-15125 > URL: https://issues.apache.org/jira/browse/HBASE-15125 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 2.0.0 >Reporter: chenrongwei >Assignee: chenrongwei > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15125-V001.patch, HBASE-15125-v001-for-branch-1, > HBASE-15125-v002.patch, HBASE-15125-v003.patch, HBASE-15125-v004.patch, > HBASE-15125-v004.patch, HBASE-15125-v005.patch > > > There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this > function will create a region,which want to cover all the orphan regions.But > the end key of this new region was set incorrectly.Correct region's boundary > should be [startKey,endKey),but this function create a region with boundary > of [startKey,endKey],this bug will leads to scan operation omit some data. > I think we should create the region like bellow, > // create new region on hdfs. move data into place. > HRegionInfo hri = new HRegionInfo(template.getTableName(), > orphanRegionRange.getFirst(), > Bytes.add(orphanRegionRange.getSecond(), new byte[1])); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283311#comment-15283311
]
Hudson commented on HBASE-13532:
SUCCESS: Integrated in HBase-1.2-IT #506 (See
[https://builds.apache.org/job/HBase-1.2-IT/506/])
HBASE-13532 Make UnknownScannerException less scary by giving more
(matteo.bertozzi: rev aaa43631490874a6d7ec8afdcebd8608212c8f8c)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
>
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283304#comment-15283304 ] Mikhail Antonov commented on HBASE-15780: - Agree we shouldn't be breaking that and that this code isn't likely to change. Was more thinking that in general I'd prefer that when new interfaces are opened up they're first enabled as evolving to live room for improvement, and then in 1.4 we can cast them in stone? Could add a class comment saying that thought this interface is evolving we don't expect it to change. Though I'd be fine with public-stable either... > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283299#comment-15283299
]
Sean Busbey commented on HBASE-15780:
-
{quote}
Looks good to me for 1.3. The only comment is that I would prefer to mark
interfaces as public-evolving to have a little bit more of a room if we need
to, but that's a nit in fact.
{quote}
I had considered making them IA.Evolving but 1) these things don't appear to
change much thus far and 2) this is something pretty critical to downstream
applications, so changing it has a high cost even if we say it's experimental.
{quote}
Personally I think it would be a little cleaner if UGI handled this itself the
same way it does with refreshing tickets from the credential cache, but that's
not something we can really control. I have a patch up on HADOOP-9567 that adds
a background thread for keytab based logins but it doesn't look to be getting
any traction.
{quote}
Part of what I really like on this approach is that we hide UGI entirely from
downstream users. HBase users shouldn't have to care about Hadoop
Authentication stuff, IMHO. although we are still exposing
hadoop.Configuration, that's historically been a much more straightforward part
of Hadoop.
> Expose AuthUtil as IA.Public
>
>
> Key: HBASE-15780
> URL: https://issues.apache.org/jira/browse/HBASE-15780
> Project: HBase
> Issue Type: New Feature
> Components: API, security
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-15780.1.patch
>
>
> Make AuthUtils IA.Public so that we can point it out to folks who want to
> build long-lived services that talk to secure HBase clusters without
> concerning them with Hadoop APIs like UGI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15779) Examples should use programmatic keytab auth
[ https://issues.apache.org/jira/browse/HBASE-15779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283296#comment-15283296 ] Sean Busbey commented on HBASE-15779: - Yep. I think I can get this done in a couple of hours once HBASE-15780 lands. > Examples should use programmatic keytab auth > > > Key: HBASE-15779 > URL: https://issues.apache.org/jira/browse/HBASE-15779 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 2.0.0, 1.4.0 > > > our examples should include programmatic keytab-based access for secure hbase > clusters, since most folks who look at them for building long-lived services > will need to take that approach rather than an external kinit-and-refresh > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
[
https://issues.apache.org/jira/browse/HBASE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283292#comment-15283292
]
Hadoop QA commented on HBASE-15824:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 7s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 9m
25s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
24s {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 with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 103m 21s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 130m 3s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803941/hbase-15824_v1.patch |
| JIRA Issue | HBASE-15824 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / b353e38 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 |
| findbugs | v3.0.0 |
| Test
[jira] [Commented] (HBASE-15811) Batch Get after batch Put does not fetch all Cells
[ https://issues.apache.org/jira/browse/HBASE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283286#comment-15283286 ] Mikhail Antonov commented on HBASE-15811: - [~stack] Looks like build bot didn't bother to post results here, https://builds.apache.org/job/PreCommit-HBASE-Build/1884/console, all +1 except 1 extand findbug warning. > Batch Get after batch Put does not fetch all Cells > -- > > Key: HBASE-15811 > URL: https://issues.apache.org/jira/browse/HBASE-15811 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.0.0, 1.3.0, 1.2.1, 0.98.19 >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 1.3.0, 0.98.19, 1.2.2, 1.1.6 > > Attachments: 15811.branch-1.patch, 15811.branch-1.v2.patch, > 15811.patch, Test.java, Test2.java > > > A big batch put followed by a batch get does not always return all Cells put. > See attached test program by Robert Farr that reproduces the issue. It seems > to be an issue to do with a cluster of more than one machine. Running against > a single machine does not have the problem (though the single machine may > have many regions). Robert was unable to make his program fail with a single > machine only. > I reproduced what Robert was seeing running his program. I was also unable to > make a single machine fail. In a batch of 1000 puts, I see one to three Gets > fail. I noticed too that if I wait a second after a fail and then re-get, the > Get succeeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283277#comment-15283277
]
Hudson commented on HBASE-13532:
SUCCESS: Integrated in HBase-1.3-IT #659 (See
[https://builds.apache.org/job/HBase-1.3-IT/659/])
HBASE-13532 Make UnknownScannerException less scary by giving more
(matteo.bertozzi: rev 71d45393867c83a055cba2fc0bc07eab79367d90)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
>
[jira] [Resolved] (HBASE-13783) Improve error message "Could not seek StoreFileScanner" to indicate that issue could be a bad disk
[ https://issues.apache.org/jira/browse/HBASE-13783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy resolved HBASE-13783. -- Resolution: Duplicate > Improve error message "Could not seek StoreFileScanner" to indicate that > issue could be a bad disk > -- > > Key: HBASE-13783 > URL: https://issues.apache.org/jira/browse/HBASE-13783 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Priority: Minor > Attachments: HBASE-13783.patch > > > Feedback from customers. > Following error could mean that a disk has gone bad. We have seen many users > confused by this error. > java.io.IOException: Could not seek StoreFileScanner[HFileScanner for reader > reader=hdfs:///843914879034b56117dfa6b7f3c8383d/content/b6f5e9961d2d4578aea3917c0637bb7c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13783) Improve error message "Could not seek StoreFileScanner" to indicate that issue could be a bad disk
[
https://issues.apache.org/jira/browse/HBASE-13783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283269#comment-15283269
]
Appy commented on HBASE-13783:
--
Following is the stack trace that was seen in this case. The root cause was
'invalid block magic header' and it has been fixed in
https://issues.apache.org/jira/browse/HBASE-11625. Closing this one out.
{noformat}
java.io.IOException: Could not seek StoreFileScanner[HFileScanner for reader
reader=...]
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:155)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:171)
at org.apache.hadoop.hbase.regionserver.Compactor.compact(Compactor.java:172)
at org.apache.hadoop.hbase.regionserver.Store.compact(Store.java:1156)
at org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1370)
at
org.apache.hadoop.hbase.regionserver.compactions.CompactionRequest.run(CompactionRequest.java:303)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Invalid HFile block magic: \x5Ck\x9E\xD823\xC5h
at org.apache.hadoop.hbase.io.hfile.BlockType.parse(BlockType.java:153)
at org.apache.hadoop.hbase.io.hfile.BlockType.read(BlockType.java:164)
at org.apache.hadoop.hbase.io.hfile.HFileBlock.(HFileBlock.java:256)
at
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderV2.readBlockDataInternal(HFileBlock.java:1925)
at
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderV2.readBlockData(HFileBlock.java:1703)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:343)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:755)
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:226)
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:143)
{noformat}
> Improve error message "Could not seek StoreFileScanner" to indicate that
> issue could be a bad disk
> --
>
> Key: HBASE-13783
> URL: https://issues.apache.org/jira/browse/HBASE-13783
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Priority: Minor
> Attachments: HBASE-13783.patch
>
>
> Feedback from customers.
> Following error could mean that a disk has gone bad. We have seen many users
> confused by this error.
> java.io.IOException: Could not seek StoreFileScanner[HFileScanner for reader
> reader=hdfs:///843914879034b56117dfa6b7f3c8383d/content/b6f5e9961d2d4578aea3917c0637bb7c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15827:
---
Fix Version/s: 1.2.2
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.2.2
>
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15779) Examples should use programmatic keytab auth
[ https://issues.apache.org/jira/browse/HBASE-15779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283267#comment-15283267 ] Mikhail Antonov commented on HBASE-15779: - Do you have it in mind for 1.3 as well [~busbey]? > Examples should use programmatic keytab auth > > > Key: HBASE-15779 > URL: https://issues.apache.org/jira/browse/HBASE-15779 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 2.0.0, 1.4.0 > > > our examples should include programmatic keytab-based access for secure hbase > clusters, since most folks who look at them for building long-lived services > will need to take that approach rather than an external kinit-and-refresh > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283257#comment-15283257 ] Mikhail Antonov commented on HBASE-15780: - Looks good to me for 1.3. The only comment is that I would prefer to mark interfaces as public-evolving to have a little bit more of a room if we need to, but that's a nit in fact. > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283249#comment-15283249 ] Gary Helmling commented on HBASE-15780: --- +1 on the patch. Personally I think it would be a little cleaner if UGI handled this itself the same way it does with refreshing tickets from the credential cache, but that's not something we can really control. I have a patch up on HADOOP-9567 that adds a background thread for keytab based logins but it doesn't look to be getting any traction. > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
[
https://issues.apache.org/jira/browse/HBASE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283243#comment-15283243
]
Stephen Yuan Jiang commented on HBASE-15824:
+1 LGTM
> LocalHBaseCluster gets bind exception in master info port
> -
>
> Key: HBASE-15824
> URL: https://issues.apache.org/jira/browse/HBASE-15824
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15824_v1.patch
>
>
> This is seen from Phoenix, since we already configure the ports in
> hbase-site.xml under hbase-server/src/test/resources.
> But this is also important for other {{hbase-testing-util}} consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283227#comment-15283227
]
Hadoop QA commented on HBASE-15827:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HBASE-15827 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803968/15827-branch-1.2.patch
|
| JIRA Issue | HBASE-15827 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1895/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15826) Clean up ASF license issues
[
https://issues.apache.org/jira/browse/HBASE-15826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283223#comment-15283223
]
Hadoop QA commented on HBASE-15826:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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} shellcheck {color} | {color:green} 0m
3s {color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} shelldocs {color} | {color:green} 0m
2s {color} | {color:green} There were no new shelldocs issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
26s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 1m 45s
{color} | {color:red} Patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 11m 41s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803962/HBASE-15826-HBASE-14850.patch
|
| JIRA Issue | HBASE-15826 |
| Optional Tests | asflicense shellcheck shelldocs |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | HBASE-14850 / e002553 |
| shellcheck | v0.3.3 (This is an old version that has serious bugs. Consider
upgrading.) |
| asflicense |
https://builds.apache.org/job/PreCommit-HBASE-Build/1892/artifact/patchprocess/patch-asflicense-problems.txt
|
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1892/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Clean up ASF license issues
> ---
>
> Key: HBASE-15826
> URL: https://issues.apache.org/jira/browse/HBASE-15826
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15826-HBASE-14850.patch
>
>
> Gotta make sure that everything is well licensed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283225#comment-15283225
]
Stephen Yuan Jiang commented on HBASE-15827:
+1 LGTM
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-13532:
Resolution: Fixed
Fix Version/s: 1.1.6
1.2.2
1.3.0
2.0.0
Status: Resolved (was: Patch Available)
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.UnknownScannerException):
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
>
[jira] [Commented] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283220#comment-15283220
]
Ted Yu commented on HBASE-15827:
TestHBaseFsck passed with the patch on branch-1.2
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283219#comment-15283219 ] Mikhail Antonov commented on HBASE-15780: - Missed this patch before, let me take a look. > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15827:
---
Assignee: Ted Yu
Status: Patch Available (was: Open)
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
[
https://issues.apache.org/jira/browse/HBASE-15827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15827:
---
Attachment: 15827-branch-1.2.patch
> Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region
> with wrong end key boundary' to 1.1 and 1.2
> -
>
> Key: HBASE-15827
> URL: https://issues.apache.org/jira/browse/HBASE-15827
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
> Attachments: 15827-branch-1.2.patch
>
>
> There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
> function will create a region,which want to cover all the orphan regions.But
> the end key of this new region was set incorrectly.Correct region's boundary
> should be [startKey,endKey),but this function create a region with boundary
> of [startKey,endKey],this bug will leads to scan operation omit some data.
> I think we should create the region like bellow,
> {code}
> // create new region on hdfs. move data into place.
> HRegionInfo hri = new HRegionInfo(template.getTableName(),
> orphanRegionRange.getFirst(),
> Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
> {code}
> This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15823) Use call once for user util
[ https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15823: -- Attachment: HBASE-15823-v2.HBASE-14850.patch > Use call once for user util > --- > > Key: HBASE-15823 > URL: https://issues.apache.org/jira/browse/HBASE-15823 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15823-v1.patch, HBASE-15823-v2-HBASE-14850.patch, > HBASE-15823-v2.HBASE-14850.patch, HBASE-15823.patch > > > Faster less locking and more correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13532) Make UnknownScannerException logging less scary
[
https://issues.apache.org/jira/browse/HBASE-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy updated HBASE-13532:
-
Attachment: HBASE-13532-branch-1.patch
> Make UnknownScannerException logging less scary
> ---
>
> Key: HBASE-13532
> URL: https://issues.apache.org/jira/browse/HBASE-13532
> Project: HBase
> Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
>Priority: Trivial
> Attachments: HBASE-13532-branch-1.patch, HBASE-13532-master.patch,
> HBASE-13532.patch
>
>
> A customer reported seeing client-side UnknownScannerExceptions after an
> HBase upgrade/restart. Restarting a RS will expire leases on the server side.
> So, given that there was no actual problem and everything was working as it
> should, reworking this exception for more appropriate logging.
> {code}
> org.apache.hadoop.hbase.UnknownScannerException:
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2012)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:98)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.consumerLoop(SimpleRpcScheduler.java:160)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.access$000(SimpleRpcScheduler.java:38)
>
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler$1.run(SimpleRpcScheduler.java:110)
>
> at java.lang.Thread.run(Thread.java:724)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
>
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
>
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:284)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.close(ScannerCallable.java:287)
>
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:153)
> at
> org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:57)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:114)
>
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:90)
>
> at org.apache.hadoop.hbase.client.ClientScanner.close(ClientScanner.java:431)
> at
> com.squareup.moco.persistence.TransactionTable.scan(TransactionTable.java:207)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.CGLIB$scan$9()
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766$$FastClassByGuice$$606c8773.invoke()
>
> at
> com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.squareup.common.metrics.TimedHistogramInterceptor.invoke(TimedHistogramInterceptor.java:29)
>
> at
> com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:75)
>
> at
> com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:55)
>
> at
> com.squareup.moco.persistence.TransactionTable$$EnhancerByGuice$$a12c1766.scan()
>
> at
> com.squareup.moco.persistence.TransactionTable$1.run(TransactionTable.java:180)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.UnknownScannerException):
> org.apache.hadoop.hbase.UnknownScannerException: Name: 10092964, already
> closed?
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3043)
>
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29497)
>
[jira] [Updated] (HBASE-15826) Clean up ASF license issues
[ https://issues.apache.org/jira/browse/HBASE-15826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15826: -- Status: Patch Available (was: Open) > Clean up ASF license issues > --- > > Key: HBASE-15826 > URL: https://issues.apache.org/jira/browse/HBASE-15826 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15826-HBASE-14850.patch > > > Gotta make sure that everything is well licensed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15826) Clean up ASF license issues
[ https://issues.apache.org/jira/browse/HBASE-15826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15826: -- Attachment: HBASE-15826-HBASE-14850.patch > Clean up ASF license issues > --- > > Key: HBASE-15826 > URL: https://issues.apache.org/jira/browse/HBASE-15826 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15826-HBASE-14850.patch > > > Gotta make sure that everything is well licensed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15827) Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary' to 1.1 and 1.2
Ted Yu created HBASE-15827:
--
Summary: Backport HBASE-15125 'HBaseFsck's adoptHdfsOrphan
function creates region with wrong end key boundary' to 1.1 and 1.2
Key: HBASE-15827
URL: https://issues.apache.org/jira/browse/HBASE-15827
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this
function will create a region,which want to cover all the orphan regions.But
the end key of this new region was set incorrectly.Correct region's boundary
should be [startKey,endKey),but this function create a region with boundary of
[startKey,endKey],this bug will leads to scan operation omit some data.
I think we should create the region like bellow,
{code}
// create new region on hdfs. move data into place.
HRegionInfo hri = new HRegionInfo(template.getTableName(),
orphanRegionRange.getFirst(),
Bytes.add(orphanRegionRange.getSecond(), new byte[1]));
{code}
This is to backport to branch-1.1 and branch-1.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15823) Use call once for user util
[
https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283205#comment-15283205
]
Hadoop QA commented on HBASE-15823:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HBASE-15823 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803959/HBASE-15823-v2-HBASE-14850.patch
|
| JIRA Issue | HBASE-15823 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1891/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Use call once for user util
> ---
>
> Key: HBASE-15823
> URL: https://issues.apache.org/jira/browse/HBASE-15823
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15823-v1.patch, HBASE-15823-v2-HBASE-14850.patch,
> HBASE-15823.patch
>
>
> Faster less locking and more correct.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15825) Fix the null pointer in DynamicLogicExpressionSuite
[
https://issues.apache.org/jira/browse/HBASE-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283202#comment-15283202
]
Hadoop QA commented on HBASE-15825:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 52s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
30s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 9m
0s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
32s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 10s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 19m 14s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803946/HBASE-15825-1.patch |
| JIRA Issue | HBASE-15825 |
| Optional Tests | asflicense scalac scaladoc unit compile |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / 0e281e1 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/1888/testReport/ |
| modules | C: hbase-spark U: hbase-spark |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1888/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Fix the null pointer in DynamicLogicExpressionSuite
> ---
>
> Key: HBASE-15825
> URL: https://issues.apache.org/jira/browse/HBASE-15825
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zhan Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15825-1.patch
>
>
> It only happens in test cases. Not sure why it is not caught. Will submit
> patch soon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-15826) Clean up ASF license issues
[ https://issues.apache.org/jira/browse/HBASE-15826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark reassigned HBASE-15826: - Assignee: Elliott Clark > Clean up ASF license issues > --- > > Key: HBASE-15826 > URL: https://issues.apache.org/jira/browse/HBASE-15826 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15826) Clean up ASF license issues
[ https://issues.apache.org/jira/browse/HBASE-15826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15826: -- Description: Gotta make sure that everything is well licensed > Clean up ASF license issues > --- > > Key: HBASE-15826 > URL: https://issues.apache.org/jira/browse/HBASE-15826 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > > Gotta make sure that everything is well licensed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15826) Clean up ASF license issues
Elliott Clark created HBASE-15826: - Summary: Clean up ASF license issues Key: HBASE-15826 URL: https://issues.apache.org/jira/browse/HBASE-15826 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15823) Use call once for user util
[ https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15823: -- Status: Patch Available (was: Open) > Use call once for user util > --- > > Key: HBASE-15823 > URL: https://issues.apache.org/jira/browse/HBASE-15823 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15823-v1.patch, HBASE-15823-v2-HBASE-14850.patch, > HBASE-15823.patch > > > Faster less locking and more correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15823) Use call once for user util
[ https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15823: -- Attachment: HBASE-15823-v2-HBASE-14850.patch > Use call once for user util > --- > > Key: HBASE-15823 > URL: https://issues.apache.org/jira/browse/HBASE-15823 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15823-v1.patch, HBASE-15823-v2-HBASE-14850.patch, > HBASE-15823.patch > > > Faster less locking and more correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15816) Provide client with ability to set priority on Operations
[ https://issues.apache.org/jira/browse/HBASE-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated HBASE-15816: --- Status: Patch Available (was: Open) > Provide client with ability to set priority on Operations > -- > > Key: HBASE-15816 > URL: https://issues.apache.org/jira/browse/HBASE-15816 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: churro morales >Assignee: churro morales > Attachments: HBASE-15816-v1.patch, HBASE-15816.patch > > > First round will just be to expose the ability to set priorities for client > operations. For more background: > http://mail-archives.apache.org/mod_mbox/hbase-dev/201604.mbox/%3CCA+RK=_BG_o=q8HMptcP2WauAinmEsL+15f3YEJuz=qbpcya...@mail.gmail.com%3E > Next step would be to remove AnnotationReadingPriorityFunction and have the > client send priorities explicitly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15816) Provide client with ability to set priority on Operations
[ https://issues.apache.org/jira/browse/HBASE-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated HBASE-15816: --- Attachment: HBASE-15816-v1.patch fixed failing test. > Provide client with ability to set priority on Operations > -- > > Key: HBASE-15816 > URL: https://issues.apache.org/jira/browse/HBASE-15816 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: churro morales >Assignee: churro morales > Attachments: HBASE-15816-v1.patch, HBASE-15816.patch > > > First round will just be to expose the ability to set priorities for client > operations. For more background: > http://mail-archives.apache.org/mod_mbox/hbase-dev/201604.mbox/%3CCA+RK=_BG_o=q8HMptcP2WauAinmEsL+15f3YEJuz=qbpcya...@mail.gmail.com%3E > Next step would be to remove AnnotationReadingPriorityFunction and have the > client send priorities explicitly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15816) Provide client with ability to set priority on Operations
[ https://issues.apache.org/jira/browse/HBASE-15816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated HBASE-15816: --- Status: Open (was: Patch Available) > Provide client with ability to set priority on Operations > -- > > Key: HBASE-15816 > URL: https://issues.apache.org/jira/browse/HBASE-15816 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: churro morales >Assignee: churro morales > Attachments: HBASE-15816-v1.patch, HBASE-15816.patch > > > First round will just be to expose the ability to set priorities for client > operations. For more background: > http://mail-archives.apache.org/mod_mbox/hbase-dev/201604.mbox/%3CCA+RK=_BG_o=q8HMptcP2WauAinmEsL+15f3YEJuz=qbpcya...@mail.gmail.com%3E > Next step would be to remove AnnotationReadingPriorityFunction and have the > client send priorities explicitly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15825) Fix the null pointer in DynamicLogicExpressionSuite
[ https://issues.apache.org/jira/browse/HBASE-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283185#comment-15283185 ] Ted Yu commented on HBASE-15825: lgtm > Fix the null pointer in DynamicLogicExpressionSuite > --- > > Key: HBASE-15825 > URL: https://issues.apache.org/jira/browse/HBASE-15825 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15825-1.patch > > > It only happens in test cases. Not sure why it is not caught. Will submit > patch soon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15780: Attachment: HBASE-15780.1.patch -01 - add javadoc for AuthUtil showing how to run the chore - make all classes mentioned IA.Public/IS.Stable - mark unused methods IA.Private - remove one method used only in test. [~mantonov], any objection to this going into branch-1.3? > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15780) Expose AuthUtil as IA.Public
[ https://issues.apache.org/jira/browse/HBASE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15780: Status: Patch Available (was: Open) > Expose AuthUtil as IA.Public > > > Key: HBASE-15780 > URL: https://issues.apache.org/jira/browse/HBASE-15780 > Project: HBase > Issue Type: New Feature > Components: API, security >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15780.1.patch > > > Make AuthUtils IA.Public so that we can point it out to folks who want to > build long-lived services that talk to secure HBase clusters without > concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10358) Shell changes for setting consistency per request
[ https://issues.apache.org/jira/browse/HBASE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283179#comment-15283179 ] Jerry He commented on HBASE-10358: -- Looks good to me. +1 > Shell changes for setting consistency per request > - > > Key: HBASE-10358 > URL: https://issues.apache.org/jira/browse/HBASE-10358 > Project: HBase > Issue Type: New Feature > Components: shell >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-04-21 at 3.09.52 PM.png, Screen Shot > 2016-05-05 at 10.38.27 AM.png, shell.patch, shell_3.patch > > > We can add shell support to set consistency per request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15825) Fix the null pointer in DynamicLogicExpressionSuite
[ https://issues.apache.org/jira/browse/HBASE-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-15825: --- Status: Patch Available (was: Open) > Fix the null pointer in DynamicLogicExpressionSuite > --- > > Key: HBASE-15825 > URL: https://issues.apache.org/jira/browse/HBASE-15825 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15825-1.patch > > > It only happens in test cases. Not sure why it is not caught. Will submit > patch soon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15825) Fix the null pointer in DynamicLogicExpressionSuite
[ https://issues.apache.org/jira/browse/HBASE-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283172#comment-15283172 ] Zhan Zhang commented on HBASE-15825: [~te...@apache.org] [~jmhsieh] Can you please take a quick look? It is a straightforward fix. > Fix the null pointer in DynamicLogicExpressionSuite > --- > > Key: HBASE-15825 > URL: https://issues.apache.org/jira/browse/HBASE-15825 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15825-1.patch > > > It only happens in test cases. Not sure why it is not caught. Will submit > patch soon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15825) Fix the null pointer in DynamicLogicExpressionSuite
[ https://issues.apache.org/jira/browse/HBASE-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-15825: --- Attachment: HBASE-15825-1.patch > Fix the null pointer in DynamicLogicExpressionSuite > --- > > Key: HBASE-15825 > URL: https://issues.apache.org/jira/browse/HBASE-15825 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15825-1.patch > > > It only happens in test cases. Not sure why it is not caught. Will submit > patch soon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
[
https://issues.apache.org/jira/browse/HBASE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15824:
--
Assignee: Enis Soztutar
Status: Patch Available (was: Open)
> LocalHBaseCluster gets bind exception in master info port
> -
>
> Key: HBASE-15824
> URL: https://issues.apache.org/jira/browse/HBASE-15824
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Attachments: hbase-15824_v1.patch
>
>
> This is seen from Phoenix, since we already configure the ports in
> hbase-site.xml under hbase-server/src/test/resources.
> But this is also important for other {{hbase-testing-util}} consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
[
https://issues.apache.org/jira/browse/HBASE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15824:
--
Fix Version/s: 1.2.2
1.1.5
1.4.0
1.3.0
2.0.0
> LocalHBaseCluster gets bind exception in master info port
> -
>
> Key: HBASE-15824
> URL: https://issues.apache.org/jira/browse/HBASE-15824
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15824_v1.patch
>
>
> This is seen from Phoenix, since we already configure the ports in
> hbase-site.xml under hbase-server/src/test/resources.
> But this is also important for other {{hbase-testing-util}} consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
[
https://issues.apache.org/jira/browse/HBASE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15824:
--
Attachment: hbase-15824_v1.patch
Simple patch.
> LocalHBaseCluster gets bind exception in master info port
> -
>
> Key: HBASE-15824
> URL: https://issues.apache.org/jira/browse/HBASE-15824
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15824_v1.patch
>
>
> This is seen from Phoenix, since we already configure the ports in
> hbase-site.xml under hbase-server/src/test/resources.
> But this is also important for other {{hbase-testing-util}} consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15333) [hbase-spark] Enhance dataframe filters to handle naively encoded short, integer, long, float and double
[ https://issues.apache.org/jira/browse/HBASE-15333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283159#comment-15283159 ] Zhan Zhang commented on HBASE-15333: Open jira HBASE-15825 to fix the test case. > [hbase-spark] Enhance dataframe filters to handle naively encoded short, > integer, long, float and double > > > Key: HBASE-15333 > URL: https://issues.apache.org/jira/browse/HBASE-15333 > Project: HBase > Issue Type: Sub-task > Components: spark >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15333-1.patch, HBASE-15333-10.patch, > HBASE-15333-2.patch, HBASE-15333-3.patch, HBASE-15333-4.patch, > HBASE-15333-5.patch, HBASE-15333-6.patch, HBASE-15333-7.patch, > HBASE-15333-8.patch, HBASE-15333-9.patch > > > Currently, the range filter is based on the order of bytes. But for java > primitive type, such as short, int, long, double, float, etc, their order is > not consistent with their byte order, extra manipulation has to be in place > to take care of them correctly. > For example, for the integer range (-100, 100), the filter <= 1, the current > filter will return 0 and 1, and the right return value should be (-100, 1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15825) Fix the null pointer in DynamicLogicExpressionSuite
Zhan Zhang created HBASE-15825: -- Summary: Fix the null pointer in DynamicLogicExpressionSuite Key: HBASE-15825 URL: https://issues.apache.org/jira/browse/HBASE-15825 Project: HBase Issue Type: Sub-task Reporter: Zhan Zhang It only happens in test cases. Not sure why it is not caught. Will submit patch soon -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15125) HBaseFsck's adoptHdfsOrphan function creates region with wrong end key boundary
[ https://issues.apache.org/jira/browse/HBASE-15125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283158#comment-15283158 ] Stephen Yuan Jiang commented on HBASE-15125: We have customer hitting this issue. We should backport this JIRA to 1.1.x and 1.2.x. > HBaseFsck's adoptHdfsOrphan function creates region with wrong end key > boundary > --- > > Key: HBASE-15125 > URL: https://issues.apache.org/jira/browse/HBASE-15125 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 2.0.0 >Reporter: chenrongwei >Assignee: chenrongwei > Fix For: 2.0.0, 1.3.0, 0.98.18 > > Attachments: HBASE-15125-V001.patch, HBASE-15125-v001-for-branch-1, > HBASE-15125-v002.patch, HBASE-15125-v003.patch, HBASE-15125-v004.patch, > HBASE-15125-v004.patch, HBASE-15125-v005.patch > > > There is a bug in HBaseFsck's adoptHdfsOrphan function.At the last of this > function will create a region,which want to cover all the orphan regions.But > the end key of this new region was set incorrectly.Correct region's boundary > should be [startKey,endKey),but this function create a region with boundary > of [startKey,endKey],this bug will leads to scan operation omit some data. > I think we should create the region like bellow, > // create new region on hdfs. move data into place. > HRegionInfo hri = new HRegionInfo(template.getTableName(), > orphanRegionRange.getFirst(), > Bytes.add(orphanRegionRange.getSecond(), new byte[1])); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15824) LocalHBaseCluster gets bind exception in master info port
Enis Soztutar created HBASE-15824:
-
Summary: LocalHBaseCluster gets bind exception in master info port
Key: HBASE-15824
URL: https://issues.apache.org/jira/browse/HBASE-15824
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
This is seen from Phoenix, since we already configure the ports in
hbase-site.xml under hbase-server/src/test/resources.
But this is also important for other {{hbase-testing-util}} consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15333) [hbase-spark] Enhance dataframe filters to handle naively encoded short, integer, long, float and double
[ https://issues.apache.org/jira/browse/HBASE-15333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283153#comment-15283153 ] Zhan Zhang commented on HBASE-15333: Not sure why it is not caught during the systest. The failure happens only in test cases. Will open a followup jira to fix the issue. > [hbase-spark] Enhance dataframe filters to handle naively encoded short, > integer, long, float and double > > > Key: HBASE-15333 > URL: https://issues.apache.org/jira/browse/HBASE-15333 > Project: HBase > Issue Type: Sub-task > Components: spark >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15333-1.patch, HBASE-15333-10.patch, > HBASE-15333-2.patch, HBASE-15333-3.patch, HBASE-15333-4.patch, > HBASE-15333-5.patch, HBASE-15333-6.patch, HBASE-15333-7.patch, > HBASE-15333-8.patch, HBASE-15333-9.patch > > > Currently, the range filter is based on the order of bytes. But for java > primitive type, such as short, int, long, double, float, etc, their order is > not consistent with their byte order, extra manipulation has to be in place > to take care of them correctly. > For example, for the integer range (-100, 100), the filter <= 1, the current > filter will return 0 and 1, and the right return value should be (-100, 1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15725) make_patch.sh should add the branch name when -b is passed.
[ https://issues.apache.org/jira/browse/HBASE-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283112#comment-15283112 ] Sean Busbey commented on HBASE-15725: - +1 (curious why precommit did pick up v4, but this hasn't been through shellcheck before so I'm fine not waiting.) > make_patch.sh should add the branch name when -b is passed. > --- > > Key: HBASE-15725 > URL: https://issues.apache.org/jira/browse/HBASE-15725 > Project: HBase > Issue Type: Bug > Components: tooling >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0 > > Attachments: HBASE-15725-v4.patch, HBASE-15725-v5.patch > > > When using something other than master as the base branch we should default > to adding the branch name to the patch file name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15725) make_patch.sh should add the branch name when -b is passed.
[ https://issues.apache.org/jira/browse/HBASE-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283114#comment-15283114 ] Sean Busbey commented on HBASE-15725: - speak of Yetus and it shall appear. ;) > make_patch.sh should add the branch name when -b is passed. > --- > > Key: HBASE-15725 > URL: https://issues.apache.org/jira/browse/HBASE-15725 > Project: HBase > Issue Type: Bug > Components: tooling >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0 > > Attachments: HBASE-15725-v4.patch, HBASE-15725-v5.patch > > > When using something other than master as the base branch we should default > to adding the branch name to the patch file name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15725) make_patch.sh should add the branch name when -b is passed.
[
https://issues.apache.org/jira/browse/HBASE-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283107#comment-15283107
]
Hadoop QA commented on HBASE-15725:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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} shellcheck {color} | {color:green} 0m
4s {color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} shelldocs {color} | {color:green} 0m
1s {color} | {color:green} There were no new shelldocs issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 33s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.1 2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 12m 4s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803932/HBASE-15725-v5.patch |
| JIRA Issue | HBASE-15725 |
| Optional Tests | asflicense shellcheck shelldocs |
| uname | Linux asf910.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / b353e38 |
| shellcheck | v0.3.3 (This is an old version that has serious bugs. Consider
upgrading.) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1886/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> make_patch.sh should add the branch name when -b is passed.
> ---
>
> Key: HBASE-15725
> URL: https://issues.apache.org/jira/browse/HBASE-15725
> Project: HBase
> Issue Type: Bug
> Components: tooling
>Affects Versions: 2.0.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 2.0.0
>
> Attachments: HBASE-15725-v4.patch, HBASE-15725-v5.patch
>
>
> When using something other than master as the base branch we should default
> to adding the branch name to the patch file name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15725) make_patch.sh should add the branch name when -b is passed.
[ https://issues.apache.org/jira/browse/HBASE-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283098#comment-15283098 ] Elliott Clark commented on HBASE-15725: --- [~stack] [~misty] or [~busbey] any thoughts on this one? Trying to get making a patch for a branch just as easy as for master. > make_patch.sh should add the branch name when -b is passed. > --- > > Key: HBASE-15725 > URL: https://issues.apache.org/jira/browse/HBASE-15725 > Project: HBase > Issue Type: Bug > Components: tooling >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0 > > Attachments: HBASE-15725-v4.patch, HBASE-15725-v5.patch > > > When using something other than master as the base branch we should default > to adding the branch name to the patch file name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15725) make_patch.sh should add the branch name when -b is passed.
[ https://issues.apache.org/jira/browse/HBASE-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15725: -- Attachment: HBASE-15725-v5.patch Fixed changes. Thanks to Matt for the code review. > make_patch.sh should add the branch name when -b is passed. > --- > > Key: HBASE-15725 > URL: https://issues.apache.org/jira/browse/HBASE-15725 > Project: HBase > Issue Type: Bug > Components: tooling >Affects Versions: 2.0.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0 > > Attachments: HBASE-15725-v4.patch, HBASE-15725-v5.patch > > > When using something other than master as the base branch we should default > to adding the branch name to the patch file name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15823) Use call once for user util
[ https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15823: -- Attachment: HBASE-15823-v1.patch > Use call once for user util > --- > > Key: HBASE-15823 > URL: https://issues.apache.org/jira/browse/HBASE-15823 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15823-v1.patch, HBASE-15823.patch > > > Faster less locking and more correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15823) Use call once for user util
[ https://issues.apache.org/jira/browse/HBASE-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15823: -- Attachment: HBASE-15823.patch > Use call once for user util > --- > > Key: HBASE-15823 > URL: https://issues.apache.org/jira/browse/HBASE-15823 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15823-v1.patch, HBASE-15823.patch > > > Faster less locking and more correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15333) [hbase-spark] Enhance dataframe filters to handle naively encoded short, integer, long, float and double
[ https://issues.apache.org/jira/browse/HBASE-15333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283076#comment-15283076 ] Hudson commented on HBASE-15333: FAILURE: Integrated in HBase-Trunk_matrix #917 (See [https://builds.apache.org/job/HBase-Trunk_matrix/917/]) HBASE-15333 [hbase-spark] Enhance the dataframe filters to handle (jmhsieh: rev b353e388bb6bf315818fcde81f11131d6d539c70) * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/datasources/package.scala * hbase-spark/src/main/java/org/apache/hadoop/hbase/spark/SparkSQLPushDownFilter.java * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/DynamicLogicExpression.scala * hbase-spark/src/test/scala/org/apache/hadoop/hbase/spark/PartitionFilterSuite.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/datasources/JavaBytesEncoder.scala * hbase-spark/src/test/scala/org/apache/hadoop/hbase/spark/DynamicLogicExpressionSuite.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/DefaultSource.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/datasources/HBaseSparkConf.scala * hbase-spark/src/test/scala/org/apache/hadoop/hbase/spark/DefaultSourceSuite.scala * hbase-spark/src/main/protobuf/Filter.proto * hbase-spark/src/main/scala/org/apache/spark/sql/datasources/hbase/HBaseTableCatalog.scala * hbase-spark/src/main/scala/org/apache/hadoop/hbase/spark/datasources/NaiveEncoder.scala * hbase-spark/src/main/java/org/apache/hadoop/hbase/spark/protobuf/generated/FilterProtos.java > [hbase-spark] Enhance dataframe filters to handle naively encoded short, > integer, long, float and double > > > Key: HBASE-15333 > URL: https://issues.apache.org/jira/browse/HBASE-15333 > Project: HBase > Issue Type: Sub-task > Components: spark >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15333-1.patch, HBASE-15333-10.patch, > HBASE-15333-2.patch, HBASE-15333-3.patch, HBASE-15333-4.patch, > HBASE-15333-5.patch, HBASE-15333-6.patch, HBASE-15333-7.patch, > HBASE-15333-8.patch, HBASE-15333-9.patch > > > Currently, the range filter is based on the order of bytes. But for java > primitive type, such as short, int, long, double, float, etc, their order is > not consistent with their byte order, extra manipulation has to be in place > to take care of them correctly. > For example, for the integer range (-100, 100), the filter <= 1, the current > filter will return 0 and 1, and the right return value should be (-100, 1] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15821) Document TestUtil
[
https://issues.apache.org/jira/browse/HBASE-15821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283066#comment-15283066
]
Hadoop QA commented on HBASE-15821:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 11m
0s {color} | {color:green} HBASE-14850 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 9s
{color} | {color:green} HBASE-14850 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 43s
{color} | {color:green} HBASE-14850 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 10s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 46s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 2s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.1 2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 165m 24s
{color} | {color:green} root in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 55s
{color} | {color:red} Patch generated 5 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 199m 22s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12803885/HBASE-15821-HBASE-14850.patch
|
| JIRA Issue | HBASE-15821 |
| Optional Tests | asflicense cc unit compile |
| uname | Linux asf910.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | HBASE-14850 / b434d0e |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/1883/testReport/ |
| asflicense |
https://builds.apache.org/job/PreCommit-HBASE-Build/1883/artifact/patchprocess/patch-asflicense-problems.txt
|
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1883/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Document TestUtil
> -
>
> Key: HBASE-15821
> URL: https://issues.apache.org/jira/browse/HBASE-15821
> Project: HBase
> Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15821-HBASE-14850.patch,
> HBASE-15821-v1-HBASE-14850.patch
>
>
> Trying to keep everything documented well. Document TestUtil and how it
> should be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15403) Performance Evaluation tool isn't working as expected
[ https://issues.apache.org/jira/browse/HBASE-15403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283041#comment-15283041 ] Jerry He commented on HBASE-15403: -- Let me dig a little more. > Performance Evaluation tool isn't working as expected > - > > Key: HBASE-15403 > URL: https://issues.apache.org/jira/browse/HBASE-15403 > Project: HBase > Issue Type: Bug > Components: Performance >Affects Versions: 1.2.0 >Reporter: Appy >Priority: Critical > > hbase pe --nomapred --rows=100 --table='t4' randomWrite 10 > # count on t4 gives 620 rows > hbase pe --nomapred --rows=200 --table='t5' randomWrite 10 > # count on t5 gives 1257 rows > hbase pe --nomapred --table='t6' --rows=200 randomWrite 1 > # count on t6 gives 126 rows > I was working with 1.2.0, but it's likely that it'll also be affecting master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15403) Performance Evaluation tool isn't working as expected
[ https://issues.apache.org/jira/browse/HBASE-15403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283038#comment-15283038 ] Jerry He commented on HBASE-15403: -- Recently when I ran PerformanceEvaluation, I did notice some problem with the number of rows. It was not exactly the same problem described in this JIRA. hbase org.apache.hadoop.hbase.PerformanceEvaluation --table=TestTable1 randomWrite 1 hbase org.apache.hadoop.hbase.PerformanceEvaluation --table=TestTable5 randomWrite 5 hbase org.apache.hadoop.hbase.PerformanceEvaluation --table=TestTable10 randomWrite 10 hbase org.apache.hadoop.hbase.PerformanceEvaluation --table=TestTable10 randomWrite 20 All produced the same number of rows, and on the file system, they look like in similar size as well: hadoop fs -du -h /apps/hbase/data/data/default 786.5 M /apps/hbase/data/data/default/TestTable1 786.0 M /apps/hbase/data/data/default/TestTable10 782.0 M /apps/hbase/data/data/default/TestTable20 713.4 M /apps/hbase/data/data/default/TestTable5 HBase is 1.2.0. Looks like a regression somewhere. > Performance Evaluation tool isn't working as expected > - > > Key: HBASE-15403 > URL: https://issues.apache.org/jira/browse/HBASE-15403 > Project: HBase > Issue Type: Bug > Components: Performance >Affects Versions: 1.2.0 >Reporter: Appy >Priority: Critical > > hbase pe --nomapred --rows=100 --table='t4' randomWrite 10 > # count on t4 gives 620 rows > hbase pe --nomapred --rows=200 --table='t5' randomWrite 10 > # count on t5 gives 1257 rows > hbase pe --nomapred --table='t6' --rows=200 randomWrite 1 > # count on t6 gives 126 rows > I was working with 1.2.0, but it's likely that it'll also be affecting master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15823) Use call once for user util
Elliott Clark created HBASE-15823: - Summary: Use call once for user util Key: HBASE-15823 URL: https://issues.apache.org/jira/browse/HBASE-15823 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Assignee: Elliott Clark Faster less locking and more correct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15822) Move to the latest docker base image
Elliott Clark created HBASE-15822: - Summary: Move to the latest docker base image Key: HBASE-15822 URL: https://issues.apache.org/jira/browse/HBASE-15822 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark The base docker image got an update to use chef to set everything up. It changes some locations but should be pretty easy to migrate to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15821) Document TestUtil
[ https://issues.apache.org/jira/browse/HBASE-15821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-15821: -- Attachment: HBASE-15821-v1-HBASE-14850.patch > Document TestUtil > - > > Key: HBASE-15821 > URL: https://issues.apache.org/jira/browse/HBASE-15821 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-15821-HBASE-14850.patch, > HBASE-15821-v1-HBASE-14850.patch > > > Trying to keep everything documented well. Document TestUtil and how it > should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15812) HttpServer fails to come up against hadoop trunk
[
https://issues.apache.org/jira/browse/HBASE-15812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282890#comment-15282890
]
Ted Yu commented on HBASE-15812:
[~saint@gmail.com]:
How should we proceed ?
> HttpServer fails to come up against hadoop trunk
>
>
> Key: HBASE-15812
> URL: https://issues.apache.org/jira/browse/HBASE-15812
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Sangjin Lee
>Assignee: Ted Yu
> Fix For: 2.0.0
>
> Attachments: 15812.v1.txt, 15812.v1.txt
>
>
> If you run HBase HttpServer against the hadoop trunk, it fails.
> {noformat}
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/hadoop/metrics/MetricsServlet
> at
> org.apache.hadoop.hbase.http.HttpServer.addDefaultServlets(HttpServer.java:677)
> at
> org.apache.hadoop.hbase.http.HttpServer.initializeWebServer(HttpServer.java:546)
> at org.apache.hadoop.hbase.http.HttpServer.(HttpServer.java:500)
> at org.apache.hadoop.hbase.http.HttpServer.(HttpServer.java:104)
> at
> org.apache.hadoop.hbase.http.HttpServer$Builder.build(HttpServer.java:345)
> at org.apache.hadoop.hbase.http.InfoServer.(InfoServer.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.putUpWebUI(HRegionServer.java:1697)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:550)
> at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:333)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:139)
> ... 26 more
> {noformat}
> The hadoop trunk removed {{MetricsServlet}} (HADOOP-12504).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
