[jira] [Commented] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277659#comment-15277659
 ] 

Hudson commented on HBASE-15236:


FAILURE: Integrated in HBase-Trunk_matrix #910 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/910/])
HBASE-15236 Inconsistent cell reads over multiple bulk-loaded HFiles. In 
(stack: rev 11740570c1440254a76fae67d318c6a852cb56b8)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestStripeCompactionPolicy.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileScanner.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeyValueHeap.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreScanner.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreFile.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/util/CollectionBackedScanner.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestCompactor.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileReader.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueScanner.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueHeap.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SegmentScanner.java


> Inconsistent cell reads over multiple bulk-loaded HFiles
> 
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15236-master-v2.patch, 
> HBASE-15236-master-v3.patch, HBASE-15236-master-v4.patch, 
> HBASE-15236-master-v5.patch, HBASE-15236-master-v6.patch, 
> HBASE-15236-master-v7.patch, HBASE-15236-master-v8.patch, 
> HBASE-15236-master-v9.patch, HBASE-15236.patch, TestWithSingleHRegion.java, 
> tables_data.zip
>
>
>  If there are two bulkloaded hfiles in a region with same seqID, same 
> timestamps and duplicate keys*, get and scan may return different values for 
> a key. Not sure how this would happen, but one of our customer uploaded a 
> dataset with 2 files in a single region and both having same bulk load 
> timestamp. These files are small ~50M (I couldn't find any setting for max 
> file size that could lead to 2 files). The range of keys in two hfiles are 
> overlapping to some extent, but not fully (so the two files are because of 
> region merge).
> In such a case, depending on file sizes (used in 
> StoreFile.Comparators.SEQ_ID), we may get different values for the same cell 
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" 
> "cf:".
> To replicate this, i ran ImportTsv twice with 2 different csv files but same 
> timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a 
> single directory and loaded with LoadIncrementalHFiles. Here are the commands.
> {noformat}
> //CSV files should be in hdfs:///user/hbase/tmp
> sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv  
> -Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6 
> -Dimporttsv.separator='|' -Dimporttsv.timestamp=1 
> -Dimporttsv.bulk.output=hdfs:///user/hbase/1 t tmp
> {noformat}
> tables_data.zip contains three tables: t, t2, and t3.
> To load these tables and test with them, use the attached 
> TestWithSingleHRegion.java. (Change ROOT_DIR and TABLE_NAME variables 
> appropriately)
> Hfiles for table 't':
> 1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
> 2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2) 
> (c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)
> Get returns 5  where as Scan returns 55.
> On the other hand if I make the first hfile, the one with values 55 and 66 
> bigger in size than second hfile, then:
> Get returns 55  where as Scan returns 55.
> This can be seen in table 't2'.
> Weird things:
> 1. Get consistently returns values from larger hfile.
> 2. Scan consistently returns 55.
> Reason:
> Explanation 1: We add StoreFileScanners to heap by iterating over list of 
> store files which is kept sorted in DefaultStoreFileManger using 
> StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id, 
> then by decreasing filesize. So our larger files sizes are always in the 
> start.
> Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek() 
> scanners (type is StoreFileScanner in this case) point to KVs which compare 
> as equal, we put back the current scanner into heap, and call pollRealKV() to 
> get 

[jira] [Commented] (HBASE-15797) TestIPCUtil fails after HBASE-15795

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277658#comment-15277658
 ] 

Hudson commented on HBASE-15797:


FAILURE: Integrated in HBase-Trunk_matrix #910 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/910/])
HBASE-15797 TestIPCUtil fails after HBASE-15795 (stack: rev 
9d17e3d22a03dbff99b67837184bfe731049d56f)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/IPCUtil.java


> TestIPCUtil fails after HBASE-15795
> ---
>
> Key: HBASE-15797
> URL: https://issues.apache.org/jira/browse/HBASE-15797
> Project: HBase
>  Issue Type: Bug
>Reporter: Jurriaan Mous
>Assignee: Jurriaan Mous
> Fix For: 2.0.0
>
> Attachments: HBASE-15797.patch
>
>
> Seems an output stream is not closed after the change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15801) Upgrade checkstyle for all branches

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277656#comment-15277656
 ] 

Hudson commented on HBASE-15801:


FAILURE: Integrated in HBase-Trunk_matrix #910 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/910/])
HBASE-15801 Upgrade checkstyle for all branches (zhangduo: rev 
224b03b2a5258c819988cd02363bba7b4e0121f2)
* pom.xml


> Upgrade checkstyle for all branches
> ---
>
> Key: HBASE-15801
> URL: https://issues.apache.org/jira/browse/HBASE-15801
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 0.98.19, 1.4.0, 1.1.5
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>  Labels: checkstyle
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: HBASE-15801-0.98.patch, HBASE-15801-branch-1.1.patch, 
> HBASE-15801-branch-1.patch, HBASE-15801.patch
>
>
> We should use the same checkstyle for all branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15795) Cleanup all classes in package org.apache.hadoop.hbase.ipc for code style

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277657#comment-15277657
 ] 

Hudson commented on HBASE-15795:


FAILURE: Integrated in HBase-Trunk_matrix #910 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/910/])
HBASE-15797 TestIPCUtil fails after HBASE-15795 (stack: rev 
9d17e3d22a03dbff99b67837184bfe731049d56f)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/IPCUtil.java


> Cleanup all classes in package org.apache.hadoop.hbase.ipc for code style
> -
>
> Key: HBASE-15795
> URL: https://issues.apache.org/jira/browse/HBASE-15795
> Project: HBase
>  Issue Type: Improvement
>Reporter: Jurriaan Mous
>Assignee: Jurriaan Mous
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15795.patch
>
>
> While making adjustments for the async client I also need to fix code styling 
> on the relevant classes. I want to do it all at once for ipc package so it 
> does not mess up the diffs of future changes. I left out the classes I 
> already fixed in patch in HBASE-15793
> * Fixed import order
> * Added curly brackets to all one line if statements
> * Simplified generics with diamond operators where applicable
> * Made private fields final when they were able
> * use try with resource where it could be used
> * renamed variables which were obscuring class fields
> * Added documentation to empty @ doc fields
> * Removed unnecessary setting to null 
> * Removed unused getDelimitedMessageAsByteBuffer and readChunked methods from 
> private IPCUtil class



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15809) Basic Replication WebUI

[Matteo Bertozzi (JIRA)]

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

Matteo Bertozzi updated HBASE-15809:

Component/s: UI

> Basic Replication WebUI
> ---
>
> Key: HBASE-15809
> URL: https://issues.apache.org/jira/browse/HBASE-15809
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication, UI
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Priority: Minor
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15809-v0.patch, HBASE-15809-v0.png
>
>
> At the moment the only way to have some insight on replication from the webui 
> is looking at zkdump and metrics.
> the basic information useful to get started debugging are: peer information 
> and the view of WALs offsets for each peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15809) Basic Replication WebUI

[Matteo Bertozzi (JIRA)]

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

Matteo Bertozzi updated HBASE-15809:

Assignee: (was: Matteo Bertozzi)

> Basic Replication WebUI
> ---
>
> Key: HBASE-15809
> URL: https://issues.apache.org/jira/browse/HBASE-15809
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication, UI
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Priority: Minor
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15809-v0.patch, HBASE-15809-v0.png
>
>
> At the moment the only way to have some insight on replication from the webui 
> is looking at zkdump and metrics.
> the basic information useful to get started debugging are: peer information 
> and the view of WALs offsets for each peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15809) Basic Replication WebUI

[Matteo Bertozzi (JIRA)]

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

Matteo Bertozzi updated HBASE-15809:

Attachment: HBASE-15809-v0.png
HBASE-15809-v0.patch

v0 is a quick & dirty draft. There are a lot of assumption about the wal, 
trailer size and zk implementation. not sure how to workaround those without 
having a huge patch with changes in both wal and replication

> Basic Replication WebUI
> ---
>
> Key: HBASE-15809
> URL: https://issues.apache.org/jira/browse/HBASE-15809
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15809-v0.patch, HBASE-15809-v0.png
>
>
> At the moment the only way to have some insight on replication from the webui 
> is looking at zkdump and metrics.
> the basic information useful to get started debugging are: peer information 
> and the view of WALs offsets for each peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15809) Basic Replication WebUI

[Matteo Bertozzi (JIRA)]

Matteo Bertozzi created HBASE-15809:
---

 Summary: Basic Replication WebUI
 Key: HBASE-15809
 URL: https://issues.apache.org/jira/browse/HBASE-15809
 Project: HBase
  Issue Type: New Feature
  Components: Replication
Affects Versions: 2.0.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Minor
 Fix For: 2.0.0, 1.3.0


At the moment the only way to have some insight on replication from the webui 
is looking at zkdump and metrics.

the basic information useful to get started debugging are: peer information and 
the view of WALs offsets for each peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15798) Add Async RpcChannels to all RpcClients

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277652#comment-15277652
 ] 

Hadoop QA commented on HBASE-15798:
---

| (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 3 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 26s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 0s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s 
{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} 1m 1s 
{color} | {color:red} hbase-client in master has 1 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s 
{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 
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 4s 
{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 
50s {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 
52s {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 
28s {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 51s 
{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:red}-1{color} | {color:red} unit {color} | {color:red} 141m 35s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
32s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 174m 14s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | 
hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL |
|   | hadoop.hbase.security.visibility.TestVisibilityLabelsReplication |
|   | 
hadoop.hbase.security.visibility.TestVisibilityLabelsOpWithDifferentUsersNoACL |
|   | hadoop.hbase.security.visibility.TestVisibilityWithCheckAuths |
|   | hadoop.hbase.security.visibility.TestEnforcingScanLabelGenerator |
|   | 

[jira] [Commented] (HBASE-15415) Improve Master WebUI snapshot information

[huaxiang sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277651#comment-15277651
 ] 

huaxiang sun commented on HBASE-15415:
--

Thanks [~mbertozzi] for reviewing and committing the patch!

> Improve Master WebUI snapshot information
> -
>
> Key: HBASE-15415
> URL: https://issues.apache.org/jira/browse/HBASE-15415
> Project: HBase
>  Issue Type: Improvement
>  Components: master, snapshots
>Affects Versions: 0.94.0
>Reporter: Sean Busbey
>Assignee: huaxiang sun
>Priority: Minor
>  Labels: beginner, supportability
> Fix For: 2.0.0, 1.3.0
>
> Attachments: 1-snapshot.png, 2-snapshots.png, 
> HBASE-15415-branch-1-01.patch, HBASE-15415-branch-1-02.patch, 
> HBASE-15415-branch-1_v001.patch, HBASE-15415-v001.patch, 
> HBASE-15415-v002.patch, HBASE-15415-v003.patch, HBASE-15415-v003.patch, 
> HBASE-15415-v007.patch, HBASE-15415-v008.patch, HBASE-15415-v009.patch, 
> HBASE-15415-v010.patch, empty-snapshots.png, master-snapshot.png
>
>
> On the Master WebUI, we currently show lots of information about the space 
> used by individual snapshots.
> We should also give a total space used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277645#comment-15277645
 ] 

Hadoop QA commented on HBASE-15785:
---

| (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 
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 20s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
11s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 20s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 23s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 23s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
11s {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} 
11m 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} findbugs {color} | {color:green} 1m 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 21s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 6s 
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
9s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 25m 7s {color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12803153/HBASE-15785_V3.patch |
| JIRA Issue | HBASE-15785 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  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 | master / 3b74b6f |
| 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-15765) RPC handlers should steal from other queues in the same or higher priority

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277642#comment-15277642
 ] 

Hadoop QA commented on HBASE-15765:
---

| (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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 23s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 52s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
18s {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} 3m 1s 
{color} | {color:green} master passed {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} 1m 4s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 24s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 24s 
{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.7.0_79 {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} checkstyle {color} | {color:green} 1m 
46s {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} xml {color} | {color:green} 0m 1s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
14m 43s {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 
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 28m 6s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
20s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 70m 49s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.ipc.TestSimpleRpcScheduler |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12802961/HBASE-15765.patch |
| JIRA Issue | HBASE-15765 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  xml  |
| uname | Linux proserpina.apache.org 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 / 3b74b6f |
| Default Java | 1.7.0_79 |
| Multi-JDK versions |  

[jira] [Commented] (HBASE-15554) StoreFile$Writer.appendGeneralBloomFilter generates extra KV

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277633#comment-15277633
 ] 

ramkrishna.s.vasudevan commented on HBASE-15554:


For ROWCOL things unless we change things to work with Cell even in the hash 
algo we cannot avoid that copy. 
I will come up with an initial patch to work with cells but few things to keep 
in mind, once we move to cell then we cannot assume everything is in a single 
byte[] or BB. So how do we make the hash algo to work?  Currently since the key 
byte[] is getting used the byte representing the keylength, rowlength, 
familylength is also getting used in the hash algo. On changing it to cell can 
we still go with that assumption? First let me make a patch with Cell and see 
how it works out.

> StoreFile$Writer.appendGeneralBloomFilter generates extra KV
> 
>
> Key: HBASE-15554
> URL: https://issues.apache.org/jira/browse/HBASE-15554
> Project: HBase
>  Issue Type: Sub-task
>  Components: Performance
>Reporter: Vladimir Rodionov
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-15554.patch
>
>
> Accounts for 10% memory allocation in compaction thread when BloomFilterType 
> is ROWCOL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang updated HBASE-15615:
---
Affects Version/s: 0.98.19

> 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.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-15805) Canary test timesout if there is failed\shutdown zookeeper node in a quorum

[Vishal Khandelwal (JIRA)]

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

Vishal Khandelwal updated HBASE-15805:
--
Attachment: HBASE-15805.0.98.00.patch

> Canary test timesout if there is failed\shutdown zookeeper node in a quorum
> ---
>
> Key: HBASE-15805
> URL: https://issues.apache.org/jira/browse/HBASE-15805
> Project: HBase
>  Issue Type: Bug
>  Components: canary
>Affects Versions: 0.98.20
>Reporter: Vishal Khandelwal
> Fix For: 0.98.20
>
> Attachments: HBASE-15805.0.98.00.patch, HBASE-15805_0.98.patch
>
>
> Canary tools creates HBaseadmin object which which starts a thread to keep 
> pinging zookeeper on a regular interval. This cause delay when one of the 
> node in zookeeper is down and test timeouts.
> Canary tool is creating HBaseadmin whose isEnabled and tableExists calls  
> starts a catalog tacker --> retries for zookeeper connection. This zookeeper 
> (6s) retry happens for multiple times for scanning 390+ region it is causing 
> lot of sleeps. By removing the failed zookeeper from the test it actually 
> took not more than 9 sec where it was taking almost 8 mins. Since "sniff" 
> calls each table one by one thus causes the delay in the test.
> {code}
> 2016-04-29 09:52:13 [Thread-6-SendThread()] DEBUG 
> zookeeper.ClientCnxnSocketNIO(203): Ignoring exception during shutdown input
> java.net.SocketException: Socket is not connected
> at sun.nio.ch.Net.translateToSocketException(Net.java:123)
> at sun.nio.ch.Net.translateException(Net.java:157)
> at sun.nio.ch.Net.translateException(Net.java:163)
> at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:401)
> at 
> org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocketNIO.java:200)
> at org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1246)
> at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanAndNotifyState(ClientCnxn.java:1236)
> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1169)
> Caused by: java.nio.channels.NotYetConnectedException
> at sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:782)
> at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:399)
> ... 4 more
> 2016-04-29 09:52:13 [Thread-6-SendThread()] DEBUG 
> zookeeper.ClientCnxnSocketNIO(210): Ignoring exception during shutdown output
> java.net.SocketException: Socket is not connected
> at sun.nio.ch.Net.translateToSocketException(Net.java:123)
> at sun.nio.ch.Net.translateException(Net.java:157)
> at sun.nio.ch.Net.translateException(Net.java:163)
> at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:409)
> at 
> org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocketNIO.java:207)
> at org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1246)
> at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanAndNotifyState(ClientCnxn.java:1236)
> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1169)
> Caused by: java.nio.channels.NotYetConnectedException
> at sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:799)
> at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:407)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277630#comment-15277630
 ] 

Guanghao Zhang commented on HBASE-15615:


The findbugs result seems not related to this 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
>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.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-15615) Wrong sleep time when RegionServerCallable need retry

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277625#comment-15277625
 ] 

Hadoop QA commented on HBASE-15615:
---

| (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 19s 
{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 3s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s 
{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} 1m 1s 
{color} | {color:red} hbase-client in master has 1 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 15s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s 
{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 4s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 4s 
{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 
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
28s {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 
32s {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 51s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {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} 101m 42s 
{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} 133m 42s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12803130/HBASE-15615-v3.patch |
| JIRA Issue | HBASE-15615 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux pietas.apache.org 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-15609) Remove PB references from Result, DoubleColumnInterpreter and any such public facing class for 2.0

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277609#comment-15277609
 ] 

stack commented on HBASE-15609:
---

ok

> Remove PB references from Result, DoubleColumnInterpreter and any such public 
> facing class for 2.0
> --
>
> Key: HBASE-15609
> URL: https://issues.apache.org/jira/browse/HBASE-15609
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15609-addendum.patch, HBASE-15609.patch, 
> HBASE-15609.patch, HBASE-15609_1.patch, HBASE-15609_4.patch, 
> HBASE-15609_branch-1.patch
>
>
> This is a sub-task for HBASE-15174.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15609) Remove PB references from Result, DoubleColumnInterpreter and any such public facing class for 2.0

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277607#comment-15277607
 ] 

stack commented on HBASE-15609:
---

bq. The plan was to mark deprecated in branch-1 and 1.3 branches and in trunk 
just make the change. Correct me if am missing something.

Thats fine. A bit of a short circuit but fine.

bq. Sure. Will change to LimitedPrivate but then ColumnInterpreters and all the 
subclass will change to LimitedPrivate?

Do what you think best Sir.

bq.  but I think code in hbase-common cannot use something in hbase-server 
right? 

That is right.

> Remove PB references from Result, DoubleColumnInterpreter and any such public 
> facing class for 2.0
> --
>
> Key: HBASE-15609
> URL: https://issues.apache.org/jira/browse/HBASE-15609
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15609-addendum.patch, HBASE-15609.patch, 
> HBASE-15609.patch, HBASE-15609_1.patch, HBASE-15609_4.patch, 
> HBASE-15609_branch-1.patch
>
>
> This is a sub-task for HBASE-15174.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (HBASE-15788) Create ByteBuffer pools to work with Offheap while accepting RPC requests.

[Anoop Sam John (JIRA)]

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

Anoop Sam John reassigned HBASE-15788:
--

Assignee: Anoop Sam John

> Create ByteBuffer pools to work with Offheap while accepting RPC requests.
> --
>
> Key: HBASE-15788
> URL: https://issues.apache.org/jira/browse/HBASE-15788
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: ramkrishna.s.vasudevan
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15804) Some links in documentation are 404

[stack (JIRA)]

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

stack updated HBASE-15804:
--
Component/s: documentation

[~misty] Why your fancy linkchecker doesn't find this broke URL? Thanks boss.

> Some links in documentation are 404
> ---
>
> Key: HBASE-15804
> URL: https://issues.apache.org/jira/browse/HBASE-15804
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Heng Chen
>
> http://hbase.apache.org/book.html#security
> The link to {{Understanding User Authentication and Authorization in Apache 
> HBase}} return 404



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277595#comment-15277595
 ] 

stack commented on HBASE-11625:
---

Understood. Do on another issue I'd say. That said, this is a very nice, 
important fix. Good on you [~appy]

> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15801) Upgrade checkstyle for all branches

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277596#comment-15277596
 ] 

Hudson commented on HBASE-15801:


SUCCESS: Integrated in HBase-1.2-IT #504 (See 
[https://builds.apache.org/job/HBase-1.2-IT/504/])
HBASE-15801 Upgrade checkstyle for all branches (zhangduo: rev 
258d9602133188b7010c3da6ee91b2e1c281b61c)
* pom.xml


> Upgrade checkstyle for all branches
> ---
>
> Key: HBASE-15801
> URL: https://issues.apache.org/jira/browse/HBASE-15801
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 0.98.19, 1.4.0, 1.1.5
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>  Labels: checkstyle
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: HBASE-15801-0.98.patch, HBASE-15801-branch-1.1.patch, 
> HBASE-15801-branch-1.patch, HBASE-15801.patch
>
>
> We should use the same checkstyle for all branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277593#comment-15277593
 ] 

stack commented on HBASE-15785:
---

+1

> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver, Scanners
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch, 
> HBASE-15785_V3.patch
>
>
> {code}
>  Lock lock = locks[i];
>   lock.lock();
>   try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
>   cnt = bufferSize - startBufferOffset;
>   if (cnt > len) cnt = len;
>   ByteBuffer dup = bb.duplicate();
>   dup.limit(startBufferOffset + cnt).position(startBufferOffset);
>   mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on 
> that.. The locking is not needed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277587#comment-15277587
 ] 

Anoop Sam John commented on HBASE-15785:


bq.The idea is since we allocate the array in constructor and it does not 
change thereafter, it is safe to do away with the locks since we always 
duplicate and then set limit and position on duplicate? dup and slice are 
thread safe you think? 
Yes..  The lock is really not needed.  The BBs are already allocated at 
construction of BBArray.   We just find out offset and length in a BB to 
read/write.  And we duplicate the BBs and set position and limit on this.  Ya 
that function is thread safe as long as no one else doing a position/limit set. 

> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver, Scanners
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch, 
> HBASE-15785_V3.patch
>
>
> {code}
>  Lock lock = locks[i];
>   lock.lock();
>   try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
>   cnt = bufferSize - startBufferOffset;
>   if (cnt > len) cnt = len;
>   ByteBuffer dup = bb.duplicate();
>   dup.limit(startBufferOffset + cnt).position(startBufferOffset);
>   mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on 
> that.. The locking is not needed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[Anoop Sam John (JIRA)]

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

Anoop Sam John updated HBASE-15785:
---
Attachment: HBASE-15785_V3.patch

> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver, Scanners
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch, 
> HBASE-15785_V3.patch
>
>
> {code}
>  Lock lock = locks[i];
>   lock.lock();
>   try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
>   cnt = bufferSize - startBufferOffset;
>   if (cnt > len) cnt = len;
>   ByteBuffer dup = bb.duplicate();
>   dup.limit(startBufferOffset + cnt).position(startBufferOffset);
>   mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on 
> that.. The locking is not needed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15179) Cell/DBB end-to-end on the write-path

[Anoop Sam John (JIRA)]

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

Anoop Sam John updated HBASE-15179:
---
Description: 
Umbrella jira to make the HBase write path off heap E2E. We have to make sure 
we have Cells flowing in entire write path. Starting from request received in 
RPC layer, till the Cells get flushed out as HFiles, we have to keep the Cell 
data off heap.

https://docs.google.com/document/d/1fj5P8JeutQ-Uadb29ChDscMuMaJqaMNRI86C4k5S1rQ/edit

  was:Umbrella jira to make the HBase write path off heap E2E. We have to make 
sure we have Cells flowing in entire write path. Starting from request received 
in RPC layer, till the Cells get flushed out as HFiles, we have to keep the 
Cell data off heap.


> Cell/DBB end-to-end on the write-path
> -
>
> Key: HBASE-15179
> URL: https://issues.apache.org/jira/browse/HBASE-15179
> Project: HBase
>  Issue Type: Umbrella
>  Components: regionserver
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
>
> Umbrella jira to make the HBase write path off heap E2E. We have to make sure 
> we have Cells flowing in entire write path. Starting from request received in 
> RPC layer, till the Cells get flushed out as HFiles, we have to keep the Cell 
> data off heap.
> https://docs.google.com/document/d/1fj5P8JeutQ-Uadb29ChDscMuMaJqaMNRI86C4k5S1rQ/edit



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277589#comment-15277589
 ] 

Anoop Sam John commented on HBASE-15785:


In V2 patch I missed the duplicate in the multiple() function so it was 
problematic with multi threaded. Now corrected.

> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver, Scanners
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch, 
> HBASE-15785_V3.patch
>
>
> {code}
>  Lock lock = locks[i];
>   lock.lock();
>   try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
>   cnt = bufferSize - startBufferOffset;
>   if (cnt > len) cnt = len;
>   ByteBuffer dup = bb.duplicate();
>   dup.limit(startBufferOffset + cnt).position(startBufferOffset);
>   mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on 
> that.. The locking is not needed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277572#comment-15277572
 ] 

Hudson commented on HBASE-11625:


FAILURE: Integrated in HBase-1.4 #145 (See 
[https://builds.apache.org/job/HBase-1.4/145/])
HBASE-11625 - Verifies data before building HFileBlock. - Adds (stack: rev 
2f282aca15b7f36573744ff72bde2d8d07f2f384)
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/ChecksumUtil.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestChecksum.java


> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15799) Two Shell 'close_region' Example Syntaxes Don't Work

[Ted Yu (JIRA)]

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

Ted Yu updated HBASE-15799:
---
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Thanks for the patch, Matt.

> Two Shell 'close_region' Example Syntaxes Don't Work
> 
>
> Key: HBASE-15799
> URL: https://issues.apache.org/jira/browse/HBASE-15799
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Matt Warhaftig
>Assignee: Matt Warhaftig
>Priority: Minor
> Attachments: hbase-15799-v1.patch
>
>
> The close_region shell command's help message lists the following usage 
> syntaxes:
> {noformat}
> hbase> close_region 'REGIONNAME'
> hbase> close_region 'REGIONNAME', 'SERVER_NAME'
> hbase> close_region 'ENCODED_REGIONNAME'
> hbase> close_region 'ENCODED_REGIONNAME', 'SERVER_NAME'
> {noformat}
> admin.rb's current code (with close_region method being the entry point) is:
> {code}
> def close_region(region_name, server)
>   if (server == nil || !closeEncodedRegion?(region_name, server))
> @admin.closeRegion(region_name, server)
>   end
> end
> def closeEncodedRegion?(region_name, server)
>@admin.closeRegionWithEncodedRegionName(region_name, server)
> end
> {code}
> The {{close_region 'ENCODED_REGIONNAME'}} syntax currently will not work 
> because when server = nil the {{closeEncodedRegion}} method call is skipped.
> The {{close_region 'REGIONNAME', 'SERVER_NAME'}} syntax currently will not 
> work because {{@admin.closeRegionWithEncodedRegionName}} throws an 
> NotServingRegionException (for the non-encoded region_name) that is uncaught 
> in and prevents execution from returning to {{close_region}} and the correct 
> call of {{HBaseAdmin.closeRegion}}. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277549#comment-15277549
 ] 

Hudson commented on HBASE-11625:


SUCCESS: Integrated in HBase-1.3-IT #656 (See 
[https://builds.apache.org/job/HBase-1.3-IT/656/])
HBASE-11625 - Verifies data before building HFileBlock. - Adds (stack: rev 
c732a43df19db60b34dfb083109d9f9c31083223)
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/ChecksumUtil.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestChecksum.java


> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15801) Upgrade checkstyle for all branches

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277550#comment-15277550
 ] 

Hudson commented on HBASE-15801:


SUCCESS: Integrated in HBase-1.3-IT #656 (See 
[https://builds.apache.org/job/HBase-1.3-IT/656/])
HBASE-15801 Upgrade checkstyle for all branches (zhangduo: rev 
6ba2ada1bafd8a7bfffa6b09179f0b67622578fe)
* pom.xml


> Upgrade checkstyle for all branches
> ---
>
> Key: HBASE-15801
> URL: https://issues.apache.org/jira/browse/HBASE-15801
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 0.98.19, 1.4.0, 1.1.5
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>  Labels: checkstyle
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: HBASE-15801-0.98.patch, HBASE-15801-branch-1.1.patch, 
> HBASE-15801-branch-1.patch, HBASE-15801.patch
>
>
> We should use the same checkstyle for all branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15415) Improve Master WebUI snapshot information

[Matteo Bertozzi (JIRA)]

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

Matteo Bertozzi updated HBASE-15415:

   Resolution: Fixed
Fix Version/s: (was: 0.98.20)
   Status: Resolved  (was: Patch Available)

> Improve Master WebUI snapshot information
> -
>
> Key: HBASE-15415
> URL: https://issues.apache.org/jira/browse/HBASE-15415
> Project: HBase
>  Issue Type: Improvement
>  Components: master, snapshots
>Affects Versions: 0.94.0
>Reporter: Sean Busbey
>Assignee: huaxiang sun
>Priority: Minor
>  Labels: beginner, supportability
> Fix For: 2.0.0, 1.3.0
>
> Attachments: 1-snapshot.png, 2-snapshots.png, 
> HBASE-15415-branch-1-01.patch, HBASE-15415-branch-1-02.patch, 
> HBASE-15415-branch-1_v001.patch, HBASE-15415-v001.patch, 
> HBASE-15415-v002.patch, HBASE-15415-v003.patch, HBASE-15415-v003.patch, 
> HBASE-15415-v007.patch, HBASE-15415-v008.patch, HBASE-15415-v009.patch, 
> HBASE-15415-v010.patch, empty-snapshots.png, master-snapshot.png
>
>
> On the Master WebUI, we currently show lots of information about the space 
> used by individual snapshots.
> We should also give a total space used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277539#comment-15277539
 ] 

Anoop Sam John commented on HBASE-15785:


There is an issue with V2 patch where I removed the Lock fully..  Will come up 
with new patch.

> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver, Scanners
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch
>
>
> {code}
>  Lock lock = locks[i];
>   lock.lock();
>   try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
>   cnt = bufferSize - startBufferOffset;
>   if (cnt > len) cnt = len;
>   ByteBuffer dup = bb.duplicate();
>   dup.limit(startBufferOffset + cnt).position(startBufferOffset);
>   mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on 
> that.. The locking is not needed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277531#comment-15277531
 ] 

Hudson commented on HBASE-11625:


FAILURE: Integrated in HBase-1.3 #693 (See 
[https://builds.apache.org/job/HBase-1.3/693/])
HBASE-11625 - Verifies data before building HFileBlock. - Adds (stack: rev 
c732a43df19db60b34dfb083109d9f9c31083223)
* hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestChecksum.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/ChecksumUtil.java


> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277519#comment-15277519
 ] 

Duo Zhang commented on HBASE-15536:
---

Good. Thanks.

> Make AsyncFSWAL as our default WAL
> --
>
> Key: HBASE-15536
> URL: https://issues.apache.org/jira/browse/HBASE-15536
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, 
> HBASE-15536-v3.patch, HBASE-15536-v4.patch, HBASE-15536-v5.patch, 
> HBASE-15536.patch
>
>
> As it should be predicated on passing basic cluster ITBLL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15804) Some links in documentation are 404

[Heng Chen (JIRA)]

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

Heng Chen updated HBASE-15804:
--
Summary: Some links in documentation are 404  (was: Return 404 in some 
document link)

> Some links in documentation are 404
> ---
>
> Key: HBASE-15804
> URL: https://issues.apache.org/jira/browse/HBASE-15804
> Project: HBase
>  Issue Type: Bug
>Reporter: Heng Chen
>
> http://hbase.apache.org/book.html#security
> The link to {{Understanding User Authentication and Authorization in Apache 
> HBase}} return 404



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15801) Upgrade checkstyle for all branches

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-15801:
--
  Resolution: Fixed
Hadoop Flags: Reviewed
Release Note: All active branches now use maven-checkstyle-plugin 2.17 and 
checkstyle 6.18.
  Status: Resolved  (was: Patch Available)

Pushed to all branches. Thanks [~stack].

> Upgrade checkstyle for all branches
> ---
>
> Key: HBASE-15801
> URL: https://issues.apache.org/jira/browse/HBASE-15801
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 0.98.19, 1.4.0, 1.1.5
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>  Labels: checkstyle
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: HBASE-15801-0.98.patch, HBASE-15801-branch-1.1.patch, 
> HBASE-15801-branch-1.patch, HBASE-15801.patch
>
>
> We should use the same checkstyle for all branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15791) Improve javadoc in ScheduledChore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277501#comment-15277501
 ] 

Hudson commented on HBASE-15791:


FAILURE: Integrated in HBase-1.1-JDK7 #1713 (See 
[https://builds.apache.org/job/HBase-1.1-JDK7/1713/])
HBASE-15791 Improve javadoc around ScheduledChore (jmhsieh: rev 
1b4e4ea62c2ac9c9690a596a9f3bfd27d65a24f9)
* hbase-common/src/main/java/org/apache/hadoop/hbase/ScheduledChore.java


> Improve javadoc in ScheduledChore
> -
>
> Key: HBASE-15791
> URL: https://issues.apache.org/jira/browse/HBASE-15791
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15791.patch
>
>
> Was doing a review of HBASE-15439 and feel that if we had better javadoc 
> about units we would have caught this bug much earlier.  
> Attached patch improves the situation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-15609) Remove PB references from Result, DoubleColumnInterpreter and any such public facing class for 2.0

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-15609.
---
Resolution: Fixed

> Remove PB references from Result, DoubleColumnInterpreter and any such public 
> facing class for 2.0
> --
>
> Key: HBASE-15609
> URL: https://issues.apache.org/jira/browse/HBASE-15609
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15609-addendum.patch, HBASE-15609.patch, 
> HBASE-15609.patch, HBASE-15609_1.patch, HBASE-15609_4.patch, 
> HBASE-15609_branch-1.patch
>
>
> This is a sub-task for HBASE-15174.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15791) Improve javadoc in ScheduledChore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277479#comment-15277479
 ] 

Hudson commented on HBASE-15791:


FAILURE: Integrated in HBase-1.1-JDK8 #1799 (See 
[https://builds.apache.org/job/HBase-1.1-JDK8/1799/])
HBASE-15791 Improve javadoc around ScheduledChore (jmhsieh: rev 
1b4e4ea62c2ac9c9690a596a9f3bfd27d65a24f9)
* hbase-common/src/main/java/org/apache/hadoop/hbase/ScheduledChore.java


> Improve javadoc in ScheduledChore
> -
>
> Key: HBASE-15791
> URL: https://issues.apache.org/jira/browse/HBASE-15791
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15791.patch
>
>
> Was doing a review of HBASE-15439 and feel that if we had better javadoc 
> about units we would have caught this bug much earlier.  
> Attached patch improves the situation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15740) Replication source.shippedKBs metric is undercounting because it is in KB

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277482#comment-15277482
 ] 

Hudson commented on HBASE-15740:


FAILURE: Integrated in HBase-Trunk_matrix #909 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/909/])
HBASE-15740 Replication source.shippedKBs metric is undercounting (enis: rev 
b75b2268046d8b3e872060505260289d8ee43dd5)
* 
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationGlobalSourceSource.java
* 
hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSourceSource.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/protobuf/generated/DummyRegionServerEndpointProtos.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsSource.java
* 
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSourceSourceImpl.java


> Replication source.shippedKBs metric is undercounting because it is in KB
> -
>
> Key: HBASE-15740
> URL: https://issues.apache.org/jira/browse/HBASE-15740
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: hbase-15740_v1.patch, hbase-15740_v2.patch
>
>
> In a cluster where there is replication going on, I've noticed that this is 
> always 0:
> {code}
> "source.shippedKBs" : 0,
> {code}
> Looking at the source reveals why:
> {code}
>   metrics.shipBatch(currentNbOperations, currentSize / 1024, 
> currentNbHFiles);
> {code}
> It is always undercounting because we discard remaining bytes after KB 
> boundary. This is specially a problem when we are always shipping small 
> batches <1KB.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15612) Minor improvements to CellCounter and RowCounter documentation

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277481#comment-15277481
 ] 

Hudson commented on HBASE-15612:


FAILURE: Integrated in HBase-Trunk_matrix #909 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/909/])
HBASE-15612: Minor improvements to CellCounter and RowCounter (stack: rev 
a6e29676db1d2aa8ff40624573bfd93bf356d2b4)
* hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/CellCounter.java
* src/main/asciidoc/_chapters/ops_mgt.adoc


> Minor improvements to CellCounter and RowCounter documentation
> --
>
> Key: HBASE-15612
> URL: https://issues.apache.org/jira/browse/HBASE-15612
> Project: HBase
>  Issue Type: Improvement
>  Components: documentation, mapreduce
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-15612.patch
>
>
> Both Javadoc and the HBase Book need to reflect that is possible to specify 
> an optional time range in the command line arguments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15807) Update report-flakies.py to look for "FAILED" status in test report

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277483#comment-15277483
 ] 

Hudson commented on HBASE-15807:


FAILURE: Integrated in HBase-Trunk_matrix #909 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/909/])
HBASE-15807 - Update report-flakies.py to look for "FAILED" status in (stack: 
rev 2eced6f0393abbc6ebbe6d37fffe0184e7255457)
* dev-support/report-flakies.py


> Update report-flakies.py to look for "FAILED" status in test report
> ---
>
> Key: HBASE-15807
> URL: https://issues.apache.org/jira/browse/HBASE-15807
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15807-master-v1.patch
>
>
> It seems that testResult's output has changed and instead of marking failed 
> tests' status as "REGRESSION" (like 
> [here|https://builds.apache.org/view/All/job/HBase-Trunk_matrix/jdk=latest1.7,label=yahoo-not-h2/888/testReport/api/json]),
>  it now marks them as "FAILED".
> Updating the script. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor

[Jingcheng Du (JIRA)]

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

Jingcheng Du updated HBASE-15784:
-
Release Note: The core pool size and max pool size of ThreadPoolExecutor 
should be the same when LinkedBlockingQueue is used. Thus the configurations 
hbase.hconnection.threads.max, hbase.hconnection.meta.lookup.threads.max, 
hbase.region.replica.replication.threads.max and 
hbase.multihconnection.threads.max are used as the number of the core threads, 
and the related configurations *.thread.core are not used any more.  (was: The 
core pool size and max pool size of ThreadPoolExecutor should be the same when 
LinkedBlockingQueue is used. Thus the configurations 
hbase.hconnection.threads.core, hbase.hconnection.meta.lookup.threads.core, 
hbase.region.replica.replication.threads.core and 
hbase.multihconnection.threads.core are not used any more.)

> MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
> 
>
> Key: HBASE-15784
> URL: https://issues.apache.org/jira/browse/HBASE-15784
> Project: HBase
>  Issue Type: Bug
>  Components: Client, Replication, Thrift
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: HBASE-15784-v2.patch, HBASE-15784.patch
>
>
> LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the 
> thread pool not to be blocked if the number of running threads in the pool is 
> less than the max pool size and the queue is not full.
> But when the core pool size of ThreadPoolExecutor is different from the max 
> pool size, the things don't go as expected. When the number of running 
> threads is the same with the core size, more requests of executions are added 
> into the LinkedBlockingQueue. And the requests can be executed again only 
> when LinkedBlockingQueue is full or some of running threads are finished.
> Thus it is better to use the same value for the core and max pool size when 
> the LinkedBlockingQueue is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277457#comment-15277457
 ] 

Appy commented on HBASE-11625:
--

Likely flaky. Both the tests passed locally.

{noformat}
git fetch apache
git checkout apache/branch-1
mvn clean test -Dtest=TestHRegion,TestFailedAppendAndSync
---
 T E S T S
---
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
support was removed in 8.0
Running org.apache.hadoop.hbase.regionserver.TestFailedAppendAndSync
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.622 sec - in 
org.apache.hadoop.hbase.regionserver.TestFailedAppendAndSync
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
support was removed in 8.0
Running org.apache.hadoop.hbase.regionserver.TestHRegion
Tests run: 102, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 51.086 sec - 
in org.apache.hadoop.hbase.regionserver.TestHRegion

Results :

Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
{noformat}

> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15296) Break out writer and reader from StoreFile

[Appy (JIRA)]

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

Appy updated HBASE-15296:
-
Attachment: HBASE-15296-branch-1.patch

> Break out writer and reader from StoreFile
> --
>
> Key: HBASE-15296
> URL: https://issues.apache.org/jira/browse/HBASE-15296
> Project: HBase
>  Issue Type: Improvement
>  Components: regionserver
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15296-branch-1.1.patch, 
> HBASE-15296-branch-1.2.patch, HBASE-15296-branch-1.patch, 
> HBASE-15296-branch-1.patch, HBASE-15296-master-v2.patch, 
> HBASE-15296-master-v3.patch, HBASE-15296-master-v4.patch, 
> HBASE-15296-master-v5.patch, HBASE-15296-master.patch
>
>
> StoreFile.java is trending to become a monolithic class, it's ~1800 lines. 
> Would it make sense to break out reader and writer (~500 lines each) into 
> separate files.
> We are doing so many different things in a single class: comparators, reader, 
> writer, other stuff; and it hurts readability a lot, to the point that just 
> reading through a piece of code require scrolling up and down to see which 
> level (reader/writer/base class level) it belongs to. These small-small 
> things really don't help while trying to understanding the code. There are 
> good reasons we don't do these often (affects existing patches, needs to be 
> done for all branches, etc). But this and a few other classes can really use 
> a single iteration of refactoring to make things a lot better.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15296) Break out writer and reader from StoreFile

[Appy (JIRA)]

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

Appy updated HBASE-15296:
-
Status: Patch Available  (was: Reopened)

> Break out writer and reader from StoreFile
> --
>
> Key: HBASE-15296
> URL: https://issues.apache.org/jira/browse/HBASE-15296
> Project: HBase
>  Issue Type: Improvement
>  Components: regionserver
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15296-branch-1.1.patch, 
> HBASE-15296-branch-1.2.patch, HBASE-15296-branch-1.patch, 
> HBASE-15296-branch-1.patch, HBASE-15296-master-v2.patch, 
> HBASE-15296-master-v3.patch, HBASE-15296-master-v4.patch, 
> HBASE-15296-master-v5.patch, HBASE-15296-master.patch
>
>
> StoreFile.java is trending to become a monolithic class, it's ~1800 lines. 
> Would it make sense to break out reader and writer (~500 lines each) into 
> separate files.
> We are doing so many different things in a single class: comparators, reader, 
> writer, other stuff; and it hurts readability a lot, to the point that just 
> reading through a piece of code require scrolling up and down to see which 
> level (reader/writer/base class level) it belongs to. These small-small 
> things really don't help while trying to understanding the code. There are 
> good reasons we don't do these often (affects existing patches, needs to be 
> done for all branches, etc). But this and a few other classes can really use 
> a single iteration of refactoring to make things a lot better.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15296) Break out writer and reader from StoreFile

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277451#comment-15277451
 ] 

Appy commented on HBASE-15296:
--

I also learned how useful can the private interface visibility be, and why we 
are reluctant to refactor our code until it's high time. 

> Break out writer and reader from StoreFile
> --
>
> Key: HBASE-15296
> URL: https://issues.apache.org/jira/browse/HBASE-15296
> Project: HBase
>  Issue Type: Improvement
>  Components: regionserver
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15296-branch-1.1.patch, 
> HBASE-15296-branch-1.2.patch, HBASE-15296-branch-1.patch, 
> HBASE-15296-master-v2.patch, HBASE-15296-master-v3.patch, 
> HBASE-15296-master-v4.patch, HBASE-15296-master-v5.patch, 
> HBASE-15296-master.patch
>
>
> StoreFile.java is trending to become a monolithic class, it's ~1800 lines. 
> Would it make sense to break out reader and writer (~500 lines each) into 
> separate files.
> We are doing so many different things in a single class: comparators, reader, 
> writer, other stuff; and it hurts readability a lot, to the point that just 
> reading through a piece of code require scrolling up and down to see which 
> level (reader/writer/base class level) it belongs to. These small-small 
> things really don't help while trying to understanding the code. There are 
> good reasons we don't do these often (affects existing patches, needs to be 
> done for all branches, etc). But this and a few other classes can really use 
> a single iteration of refactoring to make things a lot better.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15296) Break out writer and reader from StoreFile

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277449#comment-15277449
 ] 

Appy commented on HBASE-15296:
--

Fully backward compatible patch for branch-1 is here: 
https://reviews.apache.org/r/47151/.

While makes branch-1 fully backward compatible. it's not forward compatible, 
for bow. I'll make a small patch for master branch to finish this off and end 
things in fully compatible way. Here's an example of why this mess.

Say there are two functions.
1> void foo(A);
2> A foo();

The refactor moves A to B (Inner StoreFile.Reader class to upper level 
StoreFileReader class).
And the master change made was:
1> void foo(B);
2> B foo();

To make things backward compatible, the patch changes branch-1 to

add dummy class "A extends B {}"
1> void foo(B);  (This just works due to inheritance)
2> (deprecated) A foo();
2b> B foo2();

Since foo2 was not in master in first patch ,the next change will fix it. It'll 
be relatively small.

Why so painful?
- I could have just changed master to make it compatible. But not backporting 
this change to branch-1 would make backports pita. I think this one time pain 
is better than pain in many future backports (some of may not happen if not for 
this).
- I learned that such refactoring should not be follow our usual process 
(master first, then backport), but should go backward, i.e. figure out earliest 
branch that will have this change and then make way towards the master.

> Break out writer and reader from StoreFile
> --
>
> Key: HBASE-15296
> URL: https://issues.apache.org/jira/browse/HBASE-15296
> Project: HBase
>  Issue Type: Improvement
>  Components: regionserver
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15296-branch-1.1.patch, 
> HBASE-15296-branch-1.2.patch, HBASE-15296-branch-1.patch, 
> HBASE-15296-master-v2.patch, HBASE-15296-master-v3.patch, 
> HBASE-15296-master-v4.patch, HBASE-15296-master-v5.patch, 
> HBASE-15296-master.patch
>
>
> StoreFile.java is trending to become a monolithic class, it's ~1800 lines. 
> Would it make sense to break out reader and writer (~500 lines each) into 
> separate files.
> We are doing so many different things in a single class: comparators, reader, 
> writer, other stuff; and it hurts readability a lot, to the point that just 
> reading through a piece of code require scrolling up and down to see which 
> level (reader/writer/base class level) it belongs to. These small-small 
> things really don't help while trying to understanding the code. There are 
> good reasons we don't do these often (affects existing patches, needs to be 
> done for all branches, etc). But this and a few other classes can really use 
> a single iteration of refactoring to make things a lot better.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277446#comment-15277446
 ] 

Guanghao Zhang commented on HBASE-15615:


Why the 0.98 patch can't run HADOOP QA for 0.98? Is the name of patch wrong?

> 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
>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.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

[Guanghao Zhang (JIRA)]

 [ 
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-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
>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.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-15615) Wrong sleep time when RegionServerCallable need retry

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277441#comment-15277441
 ] 

Guanghao Zhang commented on HBASE-15615:


AsyncProcess.java have a comment about retry number, too.
{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;
{code}

Attach a v3 patch which fix this. But I am not sure if it break other code.



> 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
>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.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-15615) Wrong sleep time when RegionServerCallable need retry

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277430#comment-15277430
 ] 

Guanghao Zhang commented on HBASE-15615:


HBASE-15615-branch-1.1-v2.patch is for branch 1.1, 1.2, and 1.3. Because 
branch-1.0 didn't have RegionAdminServiceCallable, I attach a 
HBASE-15615-branch-1.0-v2.patch for branch 1.0.

> 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
>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.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-15615) Wrong sleep time when RegionServerCallable need retry

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277429#comment-15277429
 ] 

Guanghao Zhang commented on HBASE-15615:


HBASE-15615-branch-0.98.patch is only for 0.98.

> 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
>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.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-15236) Inconsistent cell reads over multiple bulk-loaded HFiles

[Appy (JIRA)]

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

Appy updated HBASE-15236:
-
Release Note: 
This jira fixes that following bug:
During bulkloading, if there are multiple hfiles corresponding to same region, 
and if they have same timestamps (which may have been set using 
importtsv.timestamp) and duplicate keys across them, then get and scan may 
return values coming from different hfiles.

> Inconsistent cell reads over multiple bulk-loaded HFiles
> 
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15236-master-v2.patch, 
> HBASE-15236-master-v3.patch, HBASE-15236-master-v4.patch, 
> HBASE-15236-master-v5.patch, HBASE-15236-master-v6.patch, 
> HBASE-15236-master-v7.patch, HBASE-15236-master-v8.patch, 
> HBASE-15236-master-v9.patch, HBASE-15236.patch, TestWithSingleHRegion.java, 
> tables_data.zip
>
>
>  If there are two bulkloaded hfiles in a region with same seqID, same 
> timestamps and duplicate keys*, get and scan may return different values for 
> a key. Not sure how this would happen, but one of our customer uploaded a 
> dataset with 2 files in a single region and both having same bulk load 
> timestamp. These files are small ~50M (I couldn't find any setting for max 
> file size that could lead to 2 files). The range of keys in two hfiles are 
> overlapping to some extent, but not fully (so the two files are because of 
> region merge).
> In such a case, depending on file sizes (used in 
> StoreFile.Comparators.SEQ_ID), we may get different values for the same cell 
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" 
> "cf:".
> To replicate this, i ran ImportTsv twice with 2 different csv files but same 
> timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a 
> single directory and loaded with LoadIncrementalHFiles. Here are the commands.
> {noformat}
> //CSV files should be in hdfs:///user/hbase/tmp
> sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv  
> -Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6 
> -Dimporttsv.separator='|' -Dimporttsv.timestamp=1 
> -Dimporttsv.bulk.output=hdfs:///user/hbase/1 t tmp
> {noformat}
> tables_data.zip contains three tables: t, t2, and t3.
> To load these tables and test with them, use the attached 
> TestWithSingleHRegion.java. (Change ROOT_DIR and TABLE_NAME variables 
> appropriately)
> Hfiles for table 't':
> 1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
> 2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2) 
> (c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)
> Get returns 5  where as Scan returns 55.
> On the other hand if I make the first hfile, the one with values 55 and 66 
> bigger in size than second hfile, then:
> Get returns 55  where as Scan returns 55.
> This can be seen in table 't2'.
> Weird things:
> 1. Get consistently returns values from larger hfile.
> 2. Scan consistently returns 55.
> Reason:
> Explanation 1: We add StoreFileScanners to heap by iterating over list of 
> store files which is kept sorted in DefaultStoreFileManger using 
> StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id, 
> then by decreasing filesize. So our larger files sizes are always in the 
> start.
> Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek() 
> scanners (type is StoreFileScanner in this case) point to KVs which compare 
> as equal, we put back the current scanner into heap, and call pollRealKV() to 
> get new one. While inserting, KVScannerComparator is used which compares the 
> two (one already in heap and the one being inserted) as equal and inserts it 
> after the existing one. \[1\]
> Say s1 is scanner over first hfile and s2 over second.
> 1. We scan with s2 to get values 1, 2, 3, 4
> 2. see that both scanners have c:5 as next key, put current scanner s2 back 
> in heap, take s1 out
> 4. return 55, advance s1 to key c:6
> 5. compare c:6 to c:5, put back s2 in heap since it has larger key, take out 
> s1
> 6. ignore it's value (there is code for that too), advance s2 to c:6
> Go back to step 2 with both scanners having c:6 as next key
> This is wrong because if we add a key between c:4 and c:5 to first hfile, say 
> (c:44, foo)  which makes s1 as the 'current' scanner when we hit step 2, then 
> we'll get the values - 1, 2, 3, 4, foo, 5, 6.
> (try table t3)
> Fix:
> Assign priority ids to StoreFileScanners when inserting them into heap, 
> latest hfiles get higher priority, and use them in KVComparator instead of 
> just seq id.
> \[1\] 
> 

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277418#comment-15277418
 ] 

Hadoop QA commented on HBASE-11625:
---

| (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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
17s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s 
{color} | {color:green} branch-1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
12s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
15s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
53s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s 
{color} | {color:green} branch-1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 31s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
11s {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} 3m 
54s {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 8s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 38s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 97m 36s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
12s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 113m 35s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegion |
|   | hadoop.hbase.regionserver.TestFailedAppendAndSync |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12803074/HBASE-11625-branch-1-v1.patch
 |
| JIRA Issue | HBASE-11625 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux pietas.apache.org 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 | branch-1 / d07d316 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions |  /home/jenkins/tools/java/jdk1.8.0:1.8.0 

[jira] [Commented] (HBASE-15536) Make AsyncFSWAL as our default WAL

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277389#comment-15277389
 ] 

stack commented on HBASE-15536:
---

Yeah. Seems like discussion has calmed down especially given you have addressed 
any issues folks have raised. I am sure there are other issues to be found but 
if this is the default in 2.0, we should trip over them sooner rather than 
later. Lets give it another 24 hours  and then commit. Thanks [~Apache9]

> Make AsyncFSWAL as our default WAL
> --
>
> Key: HBASE-15536
> URL: https://issues.apache.org/jira/browse/HBASE-15536
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch, 
> HBASE-15536-v3.patch, HBASE-15536-v4.patch, HBASE-15536-v5.patch, 
> HBASE-15536.patch
>
>
> As it should be predicated on passing basic cluster ITBLL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15798) Add Async RpcChannels to all RpcClients

[stack (JIRA)]

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

stack updated HBASE-15798:
--
Attachment: HBASE-15798-v1.patch

Retry now fixes for failures are in.

> Add Async RpcChannels to all RpcClients
> ---
>
> Key: HBASE-15798
> URL: https://issues.apache.org/jira/browse/HBASE-15798
> Project: HBase
>  Issue Type: New Feature
>Reporter: Jurriaan Mous
>Assignee: Jurriaan Mous
> Attachments: HBASE-15798-v1.patch, HBASE-15798-v1.patch, 
> HBASE-15798.patch
>
>
> The RpcClients all need to expose an async protobuf RpcChannel and our own 
> custom AsyncRpcChannel (without protobuf overhead) so an Async table 
> implementation can be made.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15797) TestIPCUtil fails after HBASE-15795

[stack (JIRA)]

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

stack updated HBASE-15797:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to master. Thanks for the fix [~jurmous]

> TestIPCUtil fails after HBASE-15795
> ---
>
> Key: HBASE-15797
> URL: https://issues.apache.org/jira/browse/HBASE-15797
> Project: HBase
>  Issue Type: Bug
>Reporter: Jurriaan Mous
>Assignee: Jurriaan Mous
> Fix For: 2.0.0
>
> Attachments: HBASE-15797.patch
>
>
> Seems an output stream is not closed after the change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15801) Upgrade checkstyle for all branches

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277371#comment-15277371
 ] 

stack commented on HBASE-15801:
---

Go for it [~Apache9]

> Upgrade checkstyle for all branches
> ---
>
> Key: HBASE-15801
> URL: https://issues.apache.org/jira/browse/HBASE-15801
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 0.98.19, 1.4.0, 1.1.5
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>  Labels: checkstyle
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.2.2, 0.98.20, 1.1.6
>
> Attachments: HBASE-15801-0.98.patch, HBASE-15801-branch-1.1.patch, 
> HBASE-15801-branch-1.patch, HBASE-15801.patch
>
>
> We should use the same checkstyle for all branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15791) Improve javadoc in ScheduledChore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277372#comment-15277372
 ] 

Hudson commented on HBASE-15791:


SUCCESS: Integrated in HBase-1.2 #621 (See 
[https://builds.apache.org/job/HBase-1.2/621/])
HBASE-15791 Improve javadoc around ScheduledChore (jmhsieh: rev 
4561e6c6ca7d9cb1e2d859d2eeabc67fef1079c8)
* hbase-common/src/main/java/org/apache/hadoop/hbase/ScheduledChore.java


> Improve javadoc in ScheduledChore
> -
>
> Key: HBASE-15791
> URL: https://issues.apache.org/jira/browse/HBASE-15791
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15791.patch
>
>
> Was doing a review of HBASE-15439 and feel that if we had better javadoc 
> about units we would have caught this bug much earlier.  
> Attached patch improves the situation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277366#comment-15277366
 ] 

Appy commented on HBASE-11625:
--

Branch 1.2 is vastly different. It has compression logic mixed in and what not. 
I tried backporting it to 1.2, but wasn't simple and was taking too much time. 
I *might* try again, but not sure. :)

> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles

[stack (JIRA)]

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

stack updated HBASE-15236:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to master branch. Thanks @appy for the gnarly fix. Please add a release 
note. If you put up branch-1 fix, I'll backport no problem.

> Inconsistent cell reads over multiple bulk-loaded HFiles
> 
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15236-master-v2.patch, 
> HBASE-15236-master-v3.patch, HBASE-15236-master-v4.patch, 
> HBASE-15236-master-v5.patch, HBASE-15236-master-v6.patch, 
> HBASE-15236-master-v7.patch, HBASE-15236-master-v8.patch, 
> HBASE-15236-master-v9.patch, HBASE-15236.patch, TestWithSingleHRegion.java, 
> tables_data.zip
>
>
>  If there are two bulkloaded hfiles in a region with same seqID, same 
> timestamps and duplicate keys*, get and scan may return different values for 
> a key. Not sure how this would happen, but one of our customer uploaded a 
> dataset with 2 files in a single region and both having same bulk load 
> timestamp. These files are small ~50M (I couldn't find any setting for max 
> file size that could lead to 2 files). The range of keys in two hfiles are 
> overlapping to some extent, but not fully (so the two files are because of 
> region merge).
> In such a case, depending on file sizes (used in 
> StoreFile.Comparators.SEQ_ID), we may get different values for the same cell 
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" 
> "cf:".
> To replicate this, i ran ImportTsv twice with 2 different csv files but same 
> timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a 
> single directory and loaded with LoadIncrementalHFiles. Here are the commands.
> {noformat}
> //CSV files should be in hdfs:///user/hbase/tmp
> sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv  
> -Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6 
> -Dimporttsv.separator='|' -Dimporttsv.timestamp=1 
> -Dimporttsv.bulk.output=hdfs:///user/hbase/1 t tmp
> {noformat}
> tables_data.zip contains three tables: t, t2, and t3.
> To load these tables and test with them, use the attached 
> TestWithSingleHRegion.java. (Change ROOT_DIR and TABLE_NAME variables 
> appropriately)
> Hfiles for table 't':
> 1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
> 2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2) 
> (c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)
> Get returns 5  where as Scan returns 55.
> On the other hand if I make the first hfile, the one with values 55 and 66 
> bigger in size than second hfile, then:
> Get returns 55  where as Scan returns 55.
> This can be seen in table 't2'.
> Weird things:
> 1. Get consistently returns values from larger hfile.
> 2. Scan consistently returns 55.
> Reason:
> Explanation 1: We add StoreFileScanners to heap by iterating over list of 
> store files which is kept sorted in DefaultStoreFileManger using 
> StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id, 
> then by decreasing filesize. So our larger files sizes are always in the 
> start.
> Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek() 
> scanners (type is StoreFileScanner in this case) point to KVs which compare 
> as equal, we put back the current scanner into heap, and call pollRealKV() to 
> get new one. While inserting, KVScannerComparator is used which compares the 
> two (one already in heap and the one being inserted) as equal and inserts it 
> after the existing one. \[1\]
> Say s1 is scanner over first hfile and s2 over second.
> 1. We scan with s2 to get values 1, 2, 3, 4
> 2. see that both scanners have c:5 as next key, put current scanner s2 back 
> in heap, take s1 out
> 4. return 55, advance s1 to key c:6
> 5. compare c:6 to c:5, put back s2 in heap since it has larger key, take out 
> s1
> 6. ignore it's value (there is code for that too), advance s2 to c:6
> Go back to step 2 with both scanners having c:6 as next key
> This is wrong because if we add a key between c:4 and c:5 to first hfile, say 
> (c:44, foo)  which makes s1 as the 'current' scanner when we hit step 2, then 
> we'll get the values - 1, 2, 3, 4, foo, 5, 6.
> (try table t3)
> Fix:
> Assign priority ids to StoreFileScanners when inserting them into heap, 
> latest hfiles get higher priority, and use them in KVComparator instead of 
> just seq id.
> \[1\] 
> 

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277347#comment-15277347
 ] 

stack commented on HBASE-15785:
---

The patch looks good. The idea is since we allocate the array in constructor 
and it does not change thereafter, it is safe to do away with the locks since 
we always duplicate and then set limit and position on duplicate? dup and slice 
are thread safe you think?  Good on you [~anoop.hbase]

> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver, Scanners
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch
>
>
> {code}
>  Lock lock = locks[i];
>   lock.lock();
>   try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
>   cnt = bufferSize - startBufferOffset;
>   if (cnt > len) cnt = len;
>   ByteBuffer dup = bb.duplicate();
>   dup.limit(startBufferOffset + cnt).position(startBufferOffset);
>   mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on 
> that.. The locking is not needed here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15740) Replication source.shippedKBs metric is undercounting because it is in KB

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277344#comment-15277344
 ] 

Hudson commented on HBASE-15740:


SUCCESS: Integrated in HBase-1.4 #144 (See 
[https://builds.apache.org/job/HBase-1.4/144/])
HBASE-15740 Replication source.shippedKBs metric is undercounting (enis: rev 
d07d31611395ae4e0befc04a0b8cc67adcacacb9)
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsSource.java
* 
hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSourceSource.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/protobuf/generated/DummyRegionServerEndpointProtos.java
* 
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSourceSourceImpl.java
* 
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationGlobalSourceSource.java


> Replication source.shippedKBs metric is undercounting because it is in KB
> -
>
> Key: HBASE-15740
> URL: https://issues.apache.org/jira/browse/HBASE-15740
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: hbase-15740_v1.patch, hbase-15740_v2.patch
>
>
> In a cluster where there is replication going on, I've noticed that this is 
> always 0:
> {code}
> "source.shippedKBs" : 0,
> {code}
> Looking at the source reveals why:
> {code}
>   metrics.shipBatch(currentNbOperations, currentSize / 1024, 
> currentNbHFiles);
> {code}
> It is always undercounting because we discard remaining bytes after KB 
> boundary. This is specially a problem when we are always shipping small 
> batches <1KB.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15791) Improve javadoc in ScheduledChore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277345#comment-15277345
 ] 

Hudson commented on HBASE-15791:


SUCCESS: Integrated in HBase-1.4 #144 (See 
[https://builds.apache.org/job/HBase-1.4/144/])
HBASE-15791 Improve javadoc around ScheduledChore (jmhsieh: rev 
137d891fbc241b7866bff5476bf8d195d3a9812f)
* hbase-common/src/main/java/org/apache/hadoop/hbase/ScheduledChore.java


> Improve javadoc in ScheduledChore
> -
>
> Key: HBASE-15791
> URL: https://issues.apache.org/jira/browse/HBASE-15791
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15791.patch
>
>
> Was doing a review of HBASE-15439 and feel that if we had better javadoc 
> about units we would have caught this bug much earlier.  
> Attached patch improves the situation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277320#comment-15277320
 ] 

stack commented on HBASE-11625:
---

Pushed to branch-1 and branch-1.3. It won't go back to branch-1.2. Want to put 
up another patch (smile [~appy]?)


> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[stack (JIRA)]

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

stack updated HBASE-11625:
--
Fix Version/s: 1.4.0
   1.3.0

> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277307#comment-15277307
 ] 

Hadoop QA commented on HBASE-15751:
---

| (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: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 
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 56s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 39s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m 
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
12s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped branch modules with no Java source: . {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} 2m 49s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 36s 
{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} 3m 
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 48s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 48s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 39s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 39s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m 4s 
{color} | {color:red} hbase-client: patch generated 2 new + 1 unchanged - 1 
fixed = 3 total (was 2) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 32s 
{color} | {color:red} root: patch generated 2 new + 1 unchanged - 1 fixed = 3 
total (was 2) {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
13s {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} xml {color} | {color:green} 0m 0s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m 
23s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1 
2.5.2 2.6.0. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patch modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 53s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 36s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 54s {color} 
| {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | 

[jira] [Updated] (HBASE-15808) Reduce potential bulk load intermediate space usage and waste

[Jerry He (JIRA)]

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

Jerry He updated HBASE-15808:
-
Attachment: HBASE-15808.patch

> Reduce potential bulk load intermediate space usage and waste
> -
>
> Key: HBASE-15808
> URL: https://issues.apache.org/jira/browse/HBASE-15808
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Attachments: HBASE-15808.patch
>
>
> If the bulk load input files do not match the existing region boudaries, the 
> files will be splitted.
> In the unfornate cases where the files need to be splitted multiple times,
> the process can consume unnecessary space and can even cause out of space.
> Here is over-simplified example.
> Orinal size of input files:  
>   consumed space: size --> 300GB
> After a round of splits: 
>   consumed space: size + tmpspace1 --> 300GB + 300GB
> After another round of splits: 
>   consumded space:  size + tmpspace1 + tmpspace2 --> 300GB + 300GB + 300GB
> ..
> Currently we don't do any cleanup in the process. At least all the 
> intermediate tmpspace (not the last one) can be deleted in the process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15791) Improve javadoc in ScheduledChore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277286#comment-15277286
 ] 

Hudson commented on HBASE-15791:


SUCCESS: Integrated in HBase-1.3 #692 (See 
[https://builds.apache.org/job/HBase-1.3/692/])
HBASE-15791 Improve javadoc around ScheduledChore (jmhsieh: rev 
4ef5b4e15099f9a05b72ef23ca1512e230022d9b)
* hbase-common/src/main/java/org/apache/hadoop/hbase/ScheduledChore.java


> Improve javadoc in ScheduledChore
> -
>
> Key: HBASE-15791
> URL: https://issues.apache.org/jira/browse/HBASE-15791
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15791.patch
>
>
> Was doing a review of HBASE-15439 and feel that if we had better javadoc 
> about units we would have caught this bug much earlier.  
> Attached patch improves the situation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15740) Replication source.shippedKBs metric is undercounting because it is in KB

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277285#comment-15277285
 ] 

Hudson commented on HBASE-15740:


SUCCESS: Integrated in HBase-1.3 #692 (See 
[https://builds.apache.org/job/HBase-1.3/692/])
HBASE-15740 Replication source.shippedKBs metric is undercounting (enis: rev 
4c214b50c6efae02c0eb054b5ddf514469776a9f)
* 
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSourceSourceImpl.java
* 
hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationGlobalSourceSource.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsSource.java
* 
hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/replication/regionserver/MetricsReplicationSourceSource.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/protobuf/generated/DummyRegionServerEndpointProtos.java


> Replication source.shippedKBs metric is undercounting because it is in KB
> -
>
> Key: HBASE-15740
> URL: https://issues.apache.org/jira/browse/HBASE-15740
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: hbase-15740_v1.patch, hbase-15740_v2.patch
>
>
> In a cluster where there is replication going on, I've noticed that this is 
> always 0:
> {code}
> "source.shippedKBs" : 0,
> {code}
> Looking at the source reveals why:
> {code}
>   metrics.shipBatch(currentNbOperations, currentSize / 1024, 
> currentNbHFiles);
> {code}
> It is always undercounting because we discard remaining bytes after KB 
> boundary. This is specially a problem when we are always shipping small 
> batches <1KB.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15808) Reduce potential bulk load intermediate space usage and waste

[Jerry He (JIRA)]

Jerry He created HBASE-15808:


 Summary: Reduce potential bulk load intermediate space usage and 
waste
 Key: HBASE-15808
 URL: https://issues.apache.org/jira/browse/HBASE-15808
 Project: HBase
  Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Jerry He
Assignee: Jerry He
Priority: Minor


If the bulk load input files do not match the existing region boudaries, the 
files will be splitted.
In the unfornate cases where the files need to be splitted multiple times,
the process can consume unnecessary space and can even cause out of space.

Here is over-simplified example.

Orinal size of input files:  
  consumed space: size --> 300GB
After a round of splits: 
  consumed space: size + tmpspace1 --> 300GB + 300GB
After another round of splits: 
  consumded space:  size + tmpspace1 + tmpspace2 --> 300GB + 300GB + 300GB

..

Currently we don't do any cleanup in the process. At least all the intermediate 
tmpspace (not the last one) can be deleted in the process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15792) Add on a test for locating a region

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277201#comment-15277201
 ] 

Hadoop QA commented on HBASE-15792:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 3s {color} 
| {color:red} HBASE-15792 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/12803068/HBASE-15792-v1.patch |
| JIRA Issue | HBASE-15792 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/1842/console |
| Powered by | Apache Yetus 0.2.1   http://yetus.apache.org |


This message was automatically generated.



> Add on a test for locating a region
> ---
>
> Key: HBASE-15792
> URL: https://issues.apache.org/jira/browse/HBASE-15792
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15792-v1.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15612) Minor improvements to CellCounter and RowCounter documentation

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277050#comment-15277050
 ] 

stack commented on HBASE-15612:
---

Pushed again. I seem to have messed up first commit (Our [~esteban] figured 
this).

commit a6e29676db1d2aa8ff40624573bfd93bf356d2b4
Author: Esteban Gutierrez 
Date:   Thu Apr 7 10:04:07 2016 -0700

HBASE-15612: Minor improvements to CellCounter and RowCounter documentation

Signed-off-by: stack 

> Minor improvements to CellCounter and RowCounter documentation
> --
>
> Key: HBASE-15612
> URL: https://issues.apache.org/jira/browse/HBASE-15612
> Project: HBase
>  Issue Type: Improvement
>  Components: documentation, mapreduce
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-15612.patch
>
>
> Both Javadoc and the HBase Book need to reflect that is possible to specify 
> an optional time range in the command line arguments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15791) Improve javadoc in ScheduledChore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276976#comment-15276976
 ] 

Hudson commented on HBASE-15791:


SUCCESS: Integrated in HBase-1.2-IT #503 (See 
[https://builds.apache.org/job/HBase-1.2-IT/503/])
HBASE-15791 Improve javadoc around ScheduledChore (jmhsieh: rev 
4561e6c6ca7d9cb1e2d859d2eeabc67fef1079c8)
* hbase-common/src/main/java/org/apache/hadoop/hbase/ScheduledChore.java


> Improve javadoc in ScheduledChore
> -
>
> Key: HBASE-15791
> URL: https://issues.apache.org/jira/browse/HBASE-15791
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.1.5, 1.2.2
>
> Attachments: hbase-15791.patch
>
>
> Was doing a review of HBASE-15439 and feel that if we had better javadoc 
> about units we would have caught this bug much earlier.  
> Attached patch improves the situation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15667) Add more clarity to Reference Guide related to importing Eclipse Formatter

[Misty Stanley-Jones (JIRA)]

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

Misty Stanley-Jones updated HBASE-15667:

Status: Patch Available  (was: Open)

> Add more clarity to Reference Guide related to importing Eclipse Formatter
> --
>
> Key: HBASE-15667
> URL: https://issues.apache.org/jira/browse/HBASE-15667
> Project: HBase
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Sai Teja Ranuva
>Assignee: Sai Teja Ranuva
>Priority: Trivial
>  Labels: trivial
> Attachments: HBASE-15667.patch, HBASE-15667.patch, 
> HBASE-15667_1.patch, HBASE-15667_1.patch, HBASE-15667v2.patch, donothing.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> In Hbase Reference Guide: 
> 141.1.1. Code Formatting
> in procedure bullet point 2: It is not clear what the menu item is. 
> It should be changed to the following:
> "In Preferences, click Java->Code Style->Formatter"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15667) Add more clarity to Reference Guide related to importing Eclipse Formatter

[Misty Stanley-Jones (JIRA)]

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

Misty Stanley-Jones updated HBASE-15667:

Status: Open  (was: Patch Available)

> Add more clarity to Reference Guide related to importing Eclipse Formatter
> --
>
> Key: HBASE-15667
> URL: https://issues.apache.org/jira/browse/HBASE-15667
> Project: HBase
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Sai Teja Ranuva
>Assignee: Sai Teja Ranuva
>Priority: Trivial
>  Labels: trivial
> Attachments: HBASE-15667.patch, HBASE-15667.patch, 
> HBASE-15667_1.patch, HBASE-15667_1.patch, HBASE-15667v2.patch, donothing.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> In Hbase Reference Guide: 
> 141.1.1. Code Formatting
> in procedure bullet point 2: It is not clear what the menu item is. 
> It should be changed to the following:
> "In Preferences, click Java->Code Style->Formatter"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15751:

Priority: Major  (was: Minor)

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Improvement
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Assignee: Yufeng Jiang
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15751:

Assignee: Yufeng Jiang
  Status: Patch Available  (was: Open)

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Assignee: Yufeng Jiang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15691) Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to branch-1

[Mikhail Antonov (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276947#comment-15276947
 ] 

Mikhail Antonov commented on HBASE-15691:
-

pinging [~apurtell], [~stack]. Let me know if I can help on that, I'm looking 
forward to get it in 1.3.

> Port HBASE-10205 (ConcurrentModificationException in BucketAllocator) to 
> branch-1
> -
>
> Key: HBASE-15691
> URL: https://issues.apache.org/jira/browse/HBASE-15691
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 1.3.0
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
> Fix For: 1.3.0, 1.2.2
>
> Attachments: HBASE-15691-branch-1.patch
>
>
> HBASE-10205 was committed to trunk and 0.98 branches only. To preserve 
> continuity we should commit it to branch-1. The change requires more than 
> nontrivial fixups so I will attach a backport of the change from trunk to 
> current branch-1 here. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15751:

Issue Type: Improvement  (was: Task)

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Improvement
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Assignee: Yufeng Jiang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15751:

Affects Version/s: (was: master)

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15751:

Fix Version/s: (was: master)
   2.0.0

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15751:

Component/s: dependencies

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15751) Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use zookeeper 3.5

[Sean Busbey (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276942#comment-15276942
 ] 

Sean Busbey commented on HBASE-15751:
-

IIRC, the last time we sought out a ZK version bump things quickly fell over 
and we had to back it out. I think a thread on dev@hbase (with a subject line 
that makes clear it's a [DISCUSS] thread about updating our ZK dependency) 
would be the way to start.

> Fixed HBase compilation failure with Zookeeper 3.5 and bumped HBase to use 
> zookeeper 3.5
> 
>
> Key: HBASE-15751
> URL: https://issues.apache.org/jira/browse/HBASE-15751
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, Zookeeper
>Reporter: Yufeng Jiang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15751.patch
>
>
> From zookeeper 3.5 and onwards, runFromConfig(QuorumPeerConfig config) method 
> throws AdminServerException.
> HBase uses runFromConfig in HQuorumPeer.java and hence needs to throw this 
> exception as well.
> I've created a patch to make HBase compatible with zookeeper-3.5.1-alpha. 
> However, since zookeeper 3.5+ does not have a stable version yet, I don't 
> think we should commit this patch. Instead, I suggest using this JIRA to 
> track this issue. Once zookeeper releases stable version of 3.5+, I could 
> create another patch to bump the zookeeper version in HBase trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15615) Wrong sleep time when RegionServerCallable need retry

[Mikhail Antonov (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276934#comment-15276934
 ] 

Mikhail Antonov commented on HBASE-15615:
-

Let's also make behavior in master the same as current branch-1 regarding the 
difference [~te...@apache.org] noticed, unless there's objections.

> 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
>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.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-15615) Wrong sleep time when RegionServerCallable need retry

[Mikhail Antonov (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276931#comment-15276931
 ] 

Mikhail Antonov commented on HBASE-15615:
-

Last patch for 1.1 (i believe it should apply cleanly to branch-1 overall) 
looks good to me.

Looking at TestHCM, may be good to reduce the sleep time to not prolong the 
test run time for too long, but we can do it later.

> 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
>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.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-15792) Add on a test for locating a region

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15792:
--
Status: Patch Available  (was: Open)

> Add on a test for locating a region
> ---
>
> Key: HBASE-15792
> URL: https://issues.apache.org/jira/browse/HBASE-15792
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15792-v1.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15415) Improve Master WebUI snapshot information

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276926#comment-15276926
 ] 

Hadoop QA commented on HBASE-15415:
---

| (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} 1m 
39s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s 
{color} | {color:green} branch-1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 30s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
9s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
15s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
49s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s 
{color} | {color:green} branch-1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
12s {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} 4m 
7s {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 4s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s 
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 92m 9s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
14s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 108m 37s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12803028/HBASE-15415-branch-1-02.patch
 |
| JIRA Issue | HBASE-15415 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux pietas.apache.org 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 | branch-1 / d07d316 |
| 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 | 

[jira] [Updated] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Appy (JIRA)]

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

Appy updated HBASE-11625:
-
Attachment: HBASE-11625-branch-1-v1.patch

> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-branch-1-v1.patch, HBASE-11625-master-v2.patch, 
> HBASE-11625-master-v3.patch, HBASE-11625-master.patch, HBASE-11625.patch, 
> correct-hfile, corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15471) Add num calls in priority and general queue to RS UI

[Mikhail Antonov (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276882#comment-15276882
 ] 

Mikhail Antonov commented on HBASE-15471:
-

Nice to have but never gotten to it, pushing to 1.4, if someone has time to 
work on it now please feel free to move it back to 1.3.

> Add num calls in priority and general queue to RS UI
> 
>
> Key: HBASE-15471
> URL: https://issues.apache.org/jira/browse/HBASE-15471
> Project: HBase
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 1.2.0
>Reporter: Elliott Clark
>  Labels: beginner, easy, noob
> Fix For: 1.4.0
>
>
> 1.2 added the queue size. We should add the number of calls in the queue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15792) Add on a test for locating a region

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15792:
--
Attachment: HBASE-15792-v1.patch

> Add on a test for locating a region
> ---
>
> Key: HBASE-15792
> URL: https://issues.apache.org/jira/browse/HBASE-15792
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15792-v1.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15471) Add num calls in priority and general queue to RS UI

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15471:

Fix Version/s: (was: 1.3.0)
   1.4.0

> Add num calls in priority and general queue to RS UI
> 
>
> Key: HBASE-15471
> URL: https://issues.apache.org/jira/browse/HBASE-15471
> Project: HBase
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 1.2.0
>Reporter: Elliott Clark
>  Labels: beginner, easy, noob
> Fix For: 1.4.0
>
>
> 1.2 added the queue size. We should add the number of calls in the queue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15792) Add on a test for locating a region

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15792:
--
Attachment: (was: HBASE-15792.patch)

> Add on a test for locating a region
> ---
>
> Key: HBASE-15792
> URL: https://issues.apache.org/jira/browse/HBASE-15792
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11625) Reading datablock throws "Invalid HFile block magic" and can not switch to hdfs checksum

[Enis Soztutar (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-11625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276875#comment-15276875
 ] 

Enis Soztutar commented on HBASE-11625:
---

Agreed that we should push this to all applicable branches. Nice patch. 

> Reading datablock throws "Invalid HFile block magic" and can not switch to 
> hdfs checksum 
> -
>
> Key: HBASE-11625
> URL: https://issues.apache.org/jira/browse/HBASE-11625
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.21, 0.98.4, 0.98.5, 1.0.1.1, 1.0.3
>Reporter: qian wang
>Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: 2711de1fdf73419d9f8afc6a8b86ce64.gz, 
> HBASE-11625-master-v2.patch, HBASE-11625-master-v3.patch, 
> HBASE-11625-master.patch, HBASE-11625.patch, correct-hfile, 
> corrupted-header-hfile
>
>
> when using hbase checksum,call readBlockDataInternal() in hfileblock.java, it 
> could happen file corruption but it only can switch to hdfs checksum 
> inputstream till validateBlockChecksum(). If the datablock's header corrupted 
> when b = new HFileBlock(),it throws the exception "Invalid HFile block magic" 
> and the rpc call fail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15792) Add on a test for locating a region

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15792:
--
Attachment: HBASE-15792.patch

> Add on a test for locating a region
> ---
>
> Key: HBASE-15792
> URL: https://issues.apache.org/jira/browse/HBASE-15792
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-15792.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15770) Stop using wangle's global executor

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15770:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Stop using wangle's global executor
> ---
>
> Key: HBASE-15770
> URL: https://issues.apache.org/jira/browse/HBASE-15770
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Blocker
> Attachments: HBASE-15770-v1.patch, HBASE-15770.patch
>
>
> In order to ensure that all things are closed correctly, we need to call 
> IOThreadPool#close. Doing that on the singleton is pretty bad manners. So we 
> should just use our own IOThreadPool and not use the global one at all.
> This will involve making the client have the threads.
> Passing the threads to connection pool, connection factory, etc.
> Calling close on the threads when cleaning up the client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15785) Unnecessary lock in ByteBufferArray#asSubByteBuff

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276871#comment-15276871
 ] 

Hadoop QA commented on HBASE-15785:
---

| (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 
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 27s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 16s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
43s {color} | {color:green} master passed {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 16s 
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 28s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 28s 
{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:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 15s 
{color} | {color:red} hbase-common: patch generated 6 new + 54 unchanged - 3 
fixed = 60 total (was 57) {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
10s {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 
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} findbugs {color} | {color:green} 1m 4s 
{color} | {color:green} the patch passed {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 17s 
{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} 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} 21m 48s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12803031/HBASE-15785_V2.patch |
| JIRA Issue | HBASE-15785 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux asf906.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 / 2eced6f |
| Default Java | 1.7.0_79 |
| Multi-JDK versions |  /home/jenkins/tools/java/jdk1.8.0:1.8.0