[jira] [Commented] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[
https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374290#comment-15374290
]
Hadoop QA commented on HBASE-16210:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 21s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_80 {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} 0m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {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}
26m 22s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 59s
{color} | {color:red} hbase-common generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {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 36s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 44s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 56s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 45m 16s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-common |
| | Public static org.apache.hadoop.hbase.Timestamp.values() may expose
internal representation by returning Timestamp.values At
Timestamp.java:internal representation by returning Timestamp.values At
Timestamp.java:[line 287] |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
[jira] [Commented] (HBASE-16195) Should not add chunk into chunkQueue if not using chunk pool in HeapMemStoreLAB
[ https://issues.apache.org/jira/browse/HBASE-16195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374286#comment-15374286 ] Hudson commented on HBASE-16195: SUCCESS: Integrated in HBase-1.2-IT #552 (See [https://builds.apache.org/job/HBase-1.2-IT/552/]) HBASE-16195 Should not add chunk into chunkQueue if not using chunk pool (liyu: rev ab239afb67c8c5d7a3c359ec17d278b5f579f4a7) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreChunkPool.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMemStoreLAB.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemStoreLAB.java > Should not add chunk into chunkQueue if not using chunk pool in > HeapMemStoreLAB > --- > > Key: HBASE-16195 > URL: https://issues.apache.org/jira/browse/HBASE-16195 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.1.5, 1.2.2, 0.98.20 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3 > > Attachments: HBASE-16195.patch, HBASE-16195_v2.patch, > HBASE-16195_v3.patch, HBASE-16195_v4.patch, HBASE-16195_v4.patch > > > Problem description and analysis please refer to HBASE-16193 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16197) Enchance backup delete command
[ https://issues.apache.org/jira/browse/HBASE-16197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16197: -- Attachment: HBASE-16197-v1.patch > Enchance backup delete command > -- > > Key: HBASE-16197 > URL: https://issues.apache.org/jira/browse/HBASE-16197 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-16197-v1.patch > > > Currently, backup delete command deletes only physical files/directories in > backup destination. It does not update backup system table (incremental > backup table set) and it does not delete related backup images (previous > ones), thus creating a hole in dependency chain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16198) Enhance backup history command
[
https://issues.apache.org/jira/browse/HBASE-16198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374280#comment-15374280
]
Hadoop QA commented on HBASE-16198:
---
| (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-16198 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/12817074/HBASE-16198-v1.patch |
| JIRA Issue | HBASE-16198 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/2621/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Enhance backup history command
> --
>
> Key: HBASE-16198
> URL: https://issues.apache.org/jira/browse/HBASE-16198
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 2.0.0
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: 2.0.0
>
> Attachments: HBASE-16198-v1.patch
>
>
> We need history per table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16197) Enchance backup delete command
[ https://issues.apache.org/jira/browse/HBASE-16197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16197: -- Attachment: HBASE-16157-v1.patch Patch v1 > Enchance backup delete command > -- > > Key: HBASE-16197 > URL: https://issues.apache.org/jira/browse/HBASE-16197 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > > Currently, backup delete command deletes only physical files/directories in > backup destination. It does not update backup system table (incremental > backup table set) and it does not delete related backup images (previous > ones), thus creating a hole in dependency chain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16197) Enchance backup delete command
[ https://issues.apache.org/jira/browse/HBASE-16197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16197: -- Attachment: (was: HBASE-16157-v1.patch) > Enchance backup delete command > -- > > Key: HBASE-16197 > URL: https://issues.apache.org/jira/browse/HBASE-16197 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > > Currently, backup delete command deletes only physical files/directories in > backup destination. It does not update backup system table (incremental > backup table set) and it does not delete related backup images (previous > ones), thus creating a hole in dependency chain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16198) Enhance backup history command
[ https://issues.apache.org/jira/browse/HBASE-16198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16198: -- Status: Patch Available (was: In Progress) > Enhance backup history command > -- > > Key: HBASE-16198 > URL: https://issues.apache.org/jira/browse/HBASE-16198 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-16198-v1.patch > > > We need history per table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it
[ https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374244#comment-15374244 ] Hudson commented on HBASE-16208: FAILURE: Integrated in HBase-Trunk_matrix #1218 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1218/]) HBASE-16208 Check that the row exists before attempting to remove a (eclark: rev f292048ffd91503360cb56bb9b5f60fd47e2ebe0) * hbase-client/src/main/java/org/apache/hadoop/hbase/replication/TableBasedReplicationQueuesImpl.java * hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateHBaseImpl.java > Make TableBasedReplicationQueuesImpl check that queue exists before > attempting to remove it > --- > > Key: HBASE-16208 > URL: https://issues.apache.org/jira/browse/HBASE-16208 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph > Fix For: 2.0.0 > > Attachments: HBASE-16208-v1.patch, HBASE-16208-v2.patch, > HBASE-16208.patch > > > Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId) > will cause it to delete the row with the given queue id. Yet this row is not > created until the first log is registered for the queue. This causes the > server to abort if we every try to remove a queue that has not had a log > registered to it yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[ https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374243#comment-15374243 ] Hudson commented on HBASE-16220: FAILURE: Integrated in HBase-Trunk_matrix #1218 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1218/]) HBASE-16220 Demote log level for "HRegionFileSystem - No StoreFiles for" (apurtell: rev 911706a8732262b4ce0e060900b76f84f5fdf11b) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionFileSystem.java > Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE > -- > > Key: HBASE-16220 > URL: https://issues.apache.org/jira/browse/HBASE-16220 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16220.patch > > > Messages like this can significantly accumulate in regionserver logs when a > cluster is carrying empty tables. > > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > > regionserver.HRegionFileSystem - No StoreFiles for: > > hdfs://pod/hbase/data/default/table/region/family > All this means is no data has been written into a region yet. Table > utilization information can be collected by other means for managing that. > Because many deployments run with DEBUG as the default log level, especially > when trying to track down other production issues, this message is better > logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[
https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374239#comment-15374239
]
Hadoop QA commented on HBASE-16210:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 32s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 0s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 2s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
35s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 47s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 6s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 17s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 57s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 55s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
2s {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}
46m 40s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 20s
{color} | {color:red} hbase-common generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 41s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 26s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 48s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 144m 53s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
52s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 253m 17s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-common |
| | Public static org.apache.hadoop.hbase.Timestamp.values() may expose
internal representation by returning Timestamp.values At
Timestamp.java:internal representation by returning Timestamp.values At
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Description: This is a sub-issue of [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. The main idea of HLC is described in [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with the motivation of adding it to HBase. What is this patch/issue about ? This issue attempts to add a timestamp class to hbase-common and timestamp type to HTable. This is a part of the attempt to get HLC into HBase. This patch does not interfere with the current working of HBase. Why Timestamp Class ? Timestamp class can be as an abstraction to represent time in Hbase in 64 bits. It is just used for manipulating with the 64 bits of the timestamp and is not concerned about the actual time. There are three types of timestamps. System time, Custom and HLC. Each one of it has methods to manipulate the 64 bits of timestamp. HTable changes: Added a timestamp type property to HTable. This will help HBase exist in conjunction with old type of timestamp and also the HLC which will be introduced. The default is set to custom timestamp(current way of usage of timestamp). default unset timestamp is also custom timestamp as it should be so. The default timestamp will be changed to HLC when HLC feature is introduced completely in HBase. Suggestions are welcome. was: This is a sub-issue of [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. The main idea of HLC is described in [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with the motivation of adding it to HBase. What is this patch/issue about ? This issue attempts to add a timestamp class to hbase-common and timestamp type to HTable. This is a part of the attempt to get HLC into HBase. This patch does not interfere with the current working of HBase. Why Timestamp Class ? Timestamp class can be as an abstraction to represent time in Hbase in 64 bits. It is just used for manipulating with the 64 bits of the timestamp and is not concerned about the actual time. There are three types of timestamps. System time, Custom and HLC. Each one of it has methods to manipulate the 64 bits of timestamp. HTable changes: Added a timestamp type property to HTable. This will help HBase exist in conjunction with old type of timestamp and also the HLC which will be introduced. The default is set to custom timestamp(current way of usage of timestamp). default unset timestamp is also custom timestamp as it should be so. The default timestamp will be changed to HLC when HLC feature is introduced completely in HBase. Suggestions are welcome. [~enis] - The timestamp class is the one written by you, I have not made any changes. I just changed the default timestamp of the table to Custom. [~j...@cloudera.com], [~stack] > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch, > HBASE-16210.master.5.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of >
[jira] [Commented] (HBASE-16195) Should not add chunk into chunkQueue if not using chunk pool in HeapMemStoreLAB
[ https://issues.apache.org/jira/browse/HBASE-16195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374231#comment-15374231 ] Hudson commented on HBASE-16195: SUCCESS: Integrated in HBase-1.3-IT #753 (See [https://builds.apache.org/job/HBase-1.3-IT/753/]) HBASE-16195 Should not add chunk into chunkQueue if not using chunk pool (liyu: rev 922dc33fd8146312b5b7f4428bd53ee4a087ae50) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreChunkPool.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemStoreLAB.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMemStoreLAB.java > Should not add chunk into chunkQueue if not using chunk pool in > HeapMemStoreLAB > --- > > Key: HBASE-16195 > URL: https://issues.apache.org/jira/browse/HBASE-16195 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.1.5, 1.2.2, 0.98.20 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3 > > Attachments: HBASE-16195.patch, HBASE-16195_v2.patch, > HBASE-16195_v3.patch, HBASE-16195_v4.patch, HBASE-16195_v4.patch > > > Problem description and analysis please refer to HBASE-16193 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Attachment: HBASE-16210.master.5.patch HBASE-16210.master.5.patch: Added Equals, Less methods to Timestamp class, corresponding test methods to TestTimestamp class. Removed an unused import. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch, > HBASE-16210.master.5.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Patch Available (was: Open) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch, > HBASE-16210.master.5.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Open (was: Patch Available) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16211) JMXCacheBuster restarting the metrics system might cause tests to hang
[ https://issues.apache.org/jira/browse/HBASE-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374225#comment-15374225 ] Hudson commented on HBASE-16211: FAILURE: Integrated in HBase-1.3 #781 (See [https://builds.apache.org/job/HBase-1.3/781/]) HBASE-16211 JMXCacheBuster restarting the metrics system might cause (enis: rev 5bd5f6446660932c9c2ea01d8bd48d1f012b225b) * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java > JMXCacheBuster restarting the metrics system might cause tests to hang > -- > > Key: HBASE-16211 > URL: https://issues.apache.org/jira/browse/HBASE-16211 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-16211_v1.patch > > > JMXCacheBuster restarts the metrics system. In Phoenix we are manually > injecting a sink to the metric system which gets lost when we restart the > metric system. > See PHOENIX-3062 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16195) Should not add chunk into chunkQueue if not using chunk pool in HeapMemStoreLAB
[ https://issues.apache.org/jira/browse/HBASE-16195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-16195: -- Affects Version/s: 1.1.5 1.2.2 0.98.20 > Should not add chunk into chunkQueue if not using chunk pool in > HeapMemStoreLAB > --- > > Key: HBASE-16195 > URL: https://issues.apache.org/jira/browse/HBASE-16195 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.1.5, 1.2.2, 0.98.20 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3 > > Attachments: HBASE-16195.patch, HBASE-16195_v2.patch, > HBASE-16195_v3.patch, HBASE-16195_v4.patch, HBASE-16195_v4.patch > > > Problem description and analysis please refer to HBASE-16193 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16193) Memory leak when putting plenty of duplicate cells
[
https://issues.apache.org/jira/browse/HBASE-16193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yu Li updated HBASE-16193:
--
Summary: Memory leak when putting plenty of duplicate cells (was: Memory
leak when putting plenty of duplicated cells)
> Memory leak when putting plenty of duplicate cells
> --
>
> Key: HBASE-16193
> URL: https://issues.apache.org/jira/browse/HBASE-16193
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: MemoryLeakInMemStore.png, MemoryLeakInMemStore_2.png
>
>
> Recently we suffered from a weird problem that RS heap size could not reduce
> much even after FullGC, and it kept FullGC and could hardly serve any
> request. After debugging for days, we found the root cause: we won't count in
> the allocated memory in MSLAB chunk when adding duplicated cells (including
> put and delete). We have below codes in {{AbstractMemStore#add}} (or
> {{DefaultMemStore#add}} for branch-1):
> {code}
> public long add(Cell cell) {
> Cell toAdd = maybeCloneWithAllocator(cell);
> return internalAdd(toAdd);
> }
> {code}
> where we will allocate memory in MSLAB (if using) chunk for the cell first,
> and then call {{internalAdd}}, where we could see below codes in
> {{Segment#internalAdd}} (or {{DefaultMemStore#internalAdd}} for branch-1):
> {code}
> protected long internalAdd(Cell cell) {
> boolean succ = getCellSet().add(cell);
> long s = AbstractMemStore.heapSizeChange(cell, succ);
> updateMetaInfo(cell, s);
> return s;
> }
> {code}
> So if we are writing a duplicated cell, we assume there's no heap size
> change, while actually the chunk size is taken (referenced).
> Let's assume this scenario, that there're huge amount of writing on the same
> cell (same key, different values), which is not that special in
> MachineLearning use case, and there're also few normal writes, and after some
> long time, it's possible that we have many chunks with kvs like: {{cellA,
> cellB, cellA, cellA, cellA}}, that we only counts 2 cells for each
> chunk, but actually the chunk is full. So the devil comes, that we think it's
> still not hitting flush size, while there's already GBs heapsize taken.
> There's also a more extreme case, that we only writes a single cell over and
> over again and fills one chunk quickly. Ideally the chunk should be cleared
> by GC, but unfortunately we have kept a redundant reference in
> {{HeapMemStore#chunkQueue}}, which is useless when we're not using chunkPool
> by default.
> This is the umbrella to describe the problem, and I'll open two sub-JIRAs to
> resolve the above two issues separately.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-16193) Memory leak when putting plenty of duplicated cells
[
https://issues.apache.org/jira/browse/HBASE-16193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yu Li resolved HBASE-16193.
---
Resolution: Fixed
Closing this umbrella since all sub issues resolved and fix pushed into all
0.98+ branches.
> Memory leak when putting plenty of duplicated cells
> ---
>
> Key: HBASE-16193
> URL: https://issues.apache.org/jira/browse/HBASE-16193
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: MemoryLeakInMemStore.png, MemoryLeakInMemStore_2.png
>
>
> Recently we suffered from a weird problem that RS heap size could not reduce
> much even after FullGC, and it kept FullGC and could hardly serve any
> request. After debugging for days, we found the root cause: we won't count in
> the allocated memory in MSLAB chunk when adding duplicated cells (including
> put and delete). We have below codes in {{AbstractMemStore#add}} (or
> {{DefaultMemStore#add}} for branch-1):
> {code}
> public long add(Cell cell) {
> Cell toAdd = maybeCloneWithAllocator(cell);
> return internalAdd(toAdd);
> }
> {code}
> where we will allocate memory in MSLAB (if using) chunk for the cell first,
> and then call {{internalAdd}}, where we could see below codes in
> {{Segment#internalAdd}} (or {{DefaultMemStore#internalAdd}} for branch-1):
> {code}
> protected long internalAdd(Cell cell) {
> boolean succ = getCellSet().add(cell);
> long s = AbstractMemStore.heapSizeChange(cell, succ);
> updateMetaInfo(cell, s);
> return s;
> }
> {code}
> So if we are writing a duplicated cell, we assume there's no heap size
> change, while actually the chunk size is taken (referenced).
> Let's assume this scenario, that there're huge amount of writing on the same
> cell (same key, different values), which is not that special in
> MachineLearning use case, and there're also few normal writes, and after some
> long time, it's possible that we have many chunks with kvs like: {{cellA,
> cellB, cellA, cellA, cellA}}, that we only counts 2 cells for each
> chunk, but actually the chunk is full. So the devil comes, that we think it's
> still not hitting flush size, while there's already GBs heapsize taken.
> There's also a more extreme case, that we only writes a single cell over and
> over again and fills one chunk quickly. Ideally the chunk should be cleared
> by GC, but unfortunately we have kept a redundant reference in
> {{HeapMemStore#chunkQueue}}, which is useless when we're not using chunkPool
> by default.
> This is the umbrella to describe the problem, and I'll open two sub-JIRAs to
> resolve the above two issues separately.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16219) Move meta bootstrap out of HMaster
[
https://issues.apache.org/jira/browse/HBASE-16219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374182#comment-15374182
]
Hadoop QA commented on HBASE-16219:
---
| (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} 4m
31s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 25s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 0s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 0s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
22s {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}
47m 21s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 140m 16s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
0s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 212m 55s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
| | hadoop.hbase.regionserver.TestRegionReplicas |
| | hadoop.hbase.client.TestBlockEvictionFromClient |
| Timed out junit tests |
org.apache.hadoop.hbase.regionserver.wal.TestWALReplay |
| | org.apache.hadoop.hbase.regionserver.wal.TestAsyncLogRolling |
| | org.apache.hadoop.hbase.regionserver.wal.TestLogRolling |
| | org.apache.hadoop.hbase.regionserver.wal.TestSecureAsyncWALReplay |
| | org.apache.hadoop.hbase.regionserver.wal.TestDurability |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12817539/HBASE-16219-v0.patch |
| JIRA Issue | HBASE-16219 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf910.gq1.ygridcore.net
[jira] [Updated] (HBASE-16195) Should not add chunk into chunkQueue if not using chunk pool in HeapMemStoreLAB
[ https://issues.apache.org/jira/browse/HBASE-16195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-16195: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.2.3 0.98.21 1.1.6 1.4.0 1.3.0 2.0.0 Status: Resolved (was: Patch Available) Pushed into all 0.98+ branches. Thanks all for review. > Should not add chunk into chunkQueue if not using chunk pool in > HeapMemStoreLAB > --- > > Key: HBASE-16195 > URL: https://issues.apache.org/jira/browse/HBASE-16195 > Project: HBase > Issue Type: Sub-task >Reporter: Yu Li >Assignee: Yu Li > Fix For: 2.0.0, 1.3.0, 1.4.0, 1.1.6, 0.98.21, 1.2.3 > > Attachments: HBASE-16195.patch, HBASE-16195_v2.patch, > HBASE-16195_v3.patch, HBASE-16195_v4.patch, HBASE-16195_v4.patch > > > Problem description and analysis please refer to HBASE-16193 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16211) JMXCacheBuster restarting the metrics system might cause tests to hang
[ https://issues.apache.org/jira/browse/HBASE-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374180#comment-15374180 ] Hudson commented on HBASE-16211: FAILURE: Integrated in HBase-1.4 #284 (See [https://builds.apache.org/job/HBase-1.4/284/]) HBASE-16211 JMXCacheBuster restarting the metrics system might cause (enis: rev 16be7bba53165240b3bb90fcf30126a91052ac95) * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java > JMXCacheBuster restarting the metrics system might cause tests to hang > -- > > Key: HBASE-16211 > URL: https://issues.apache.org/jira/browse/HBASE-16211 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-16211_v1.patch > > > JMXCacheBuster restarts the metrics system. In Phoenix we are manually > injecting a sink to the metric system which gets lost when we restart the > metric system. > See PHOENIX-3062 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[
https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374153#comment-15374153
]
Hadoop QA commented on HBASE-16220:
---
| (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} 14m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 42s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 55s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 49s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s {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}
40m 38s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {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 52s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 93m 24s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 168m 4s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
| | hadoop.hbase.replication.TestReplicationKillMasterRSCompressed |
| Timed out junit tests |
org.apache.hadoop.hbase.client.TestSnapshotCloneIndependence |
| | org.apache.hadoop.hbase.client.TestFromClientSide |
| | org.apache.hadoop.hbase.client.TestClientOperationInterrupt |
| |
org.apache.hadoop.hbase.client.TestCloneSnapshotFromClientWithRegionReplicas |
| | org.apache.hadoop.hbase.client.TestCloneSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12817542/HBASE-16220.patch |
| JIRA Issue | HBASE-16220 |
| Optional Tests | asflicense javac javadoc
[jira] [Commented] (HBASE-16217) Identify calling user in ObserverContext
[
https://issues.apache.org/jira/browse/HBASE-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374099#comment-15374099
]
Hadoop QA commented on HBASE-16217:
---
| (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 1s
{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
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {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}
26m 19s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 14s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 90m 4s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 132m 18s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Dead store to thisStore in
org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(int,
CompactionRequest, User) At
HStore.java:org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(int,
CompactionRequest, User) At HStore.java:[line 1555] |
| Failed junit tests | hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
| Timed out junit tests |
org.apache.hadoop.hbase.replication.TestReplicationSyncUpToolWithBulkLoadedData
|
| | org.apache.hadoop.hbase.replication.TestReplicationSmallTests |
| |
org.apache.hadoop.hbase.replication.regionserver.TestReplicationWALReaderManager
|
| |
[jira] [Commented] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[
https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374092#comment-15374092
]
Hadoop QA commented on HBASE-16210:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 27s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 7s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 10s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_80 {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
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 30s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 30s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s {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}
26m 30s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 58s
{color} | {color:red} hbase-common generated 4 new + 0 unchanged - 0 fixed = 4
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 44s
{color} | {color:green} hbase-common in the patch passed. {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} 100m 8s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
43s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 157m 27s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-common |
| | Public static org.apache.hadoop.hbase.Timestamp.values() may expose
internal representation by returning Timestamp.values At
Timestamp.java:internal representation by returning Timestamp.values At
[jira] [Created] (HBASE-16221) Thrift server drops connection on long scans
Ashu Pachauri created HBASE-16221: - Summary: Thrift server drops connection on long scans Key: HBASE-16221 URL: https://issues.apache.org/jira/browse/HBASE-16221 Project: HBase Issue Type: Bug Components: Thrift Affects Versions: 1.2.0, 2.0.0, 1.3.0 Reporter: Ashu Pachauri Thrift servers use connection cache and we drop connections after hbase.thrift.connection.max-idletime milliseconds from the last time a connection object was accessed. However, we never update this last accessed time on scan path. By default, this will cause scanners to fail after 10 minutes, if the underlying connection object is not being used along other operation paths (like put). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16169) Make RegionSizeCalculator scalable
[
https://issues.apache.org/jira/browse/HBASE-16169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374074#comment-15374074
]
Hadoop QA commented on HBASE-16169:
---
| (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 10s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 42s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 21s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 8m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s {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}
32m 50s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 10s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 21s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 21s
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 59s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 95m 1s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} |
[jira] [Commented] (HBASE-15643) Need metrics of cache hit ratio, etc for one table
[ https://issues.apache.org/jira/browse/HBASE-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374075#comment-15374075 ] Alicia Ying Shu commented on HBASE-15643: - [~eclark] [~anoop.hbase] Thanks for the comments. As mentioned by [~enis] I did some perf testing using YCSB. The perf penalty was about 3%. I attached the excel sheet here. Will prototype the idea of carrying metric reference in HRegion opening and passing it down. > Need metrics of cache hit ratio, etc for one table > -- > > Key: HBASE-15643 > URL: https://issues.apache.org/jira/browse/HBASE-15643 > Project: HBase > Issue Type: Improvement >Reporter: Heng Chen >Assignee: Alicia Ying Shu > Attachments: HBASE-15643.patch, YCSB-blockCacheTableMetrics.xlsx > > > There are many tables on our cluster, only some of them need to be read > online. > We could improve the performance of read by cache, but we need some metrics > for it at table level. There are a few we can collect: BlockCacheCount, > BlockCacheSize, BlockCacheHitCount, BlockCacheMissCount, BlockCacheHitPercent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[ https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-16220: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed > Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE > -- > > Key: HBASE-16220 > URL: https://issues.apache.org/jira/browse/HBASE-16220 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16220.patch > > > Messages like this can significantly accumulate in regionserver logs when a > cluster is carrying empty tables. > > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > > regionserver.HRegionFileSystem - No StoreFiles for: > > hdfs://pod/hbase/data/default/table/region/family > All this means is no data has been written into a region yet. Table > utilization information can be collected by other means for managing that. > Because many deployments run with DEBUG as the default log level, especially > when trying to track down other production issues, this message is better > logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15643) Need metrics of cache hit ratio, etc for one table
[ https://issues.apache.org/jira/browse/HBASE-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alicia Ying Shu updated HBASE-15643: Attachment: YCSB-blockCacheTableMetrics.xlsx > Need metrics of cache hit ratio, etc for one table > -- > > Key: HBASE-15643 > URL: https://issues.apache.org/jira/browse/HBASE-15643 > Project: HBase > Issue Type: Improvement >Reporter: Heng Chen >Assignee: Alicia Ying Shu > Attachments: HBASE-15643.patch, YCSB-blockCacheTableMetrics.xlsx > > > There are many tables on our cluster, only some of them need to be read > online. > We could improve the performance of read by cache, but we need some metrics > for it at table level. There are a few we can collect: BlockCacheCount, > BlockCacheSize, BlockCacheHitCount, BlockCacheMissCount, BlockCacheHitPercent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[ https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373999#comment-15373999 ] Andrew Purtell commented on HBASE-16220: Thanks [~mbertozzi], committing > Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE > -- > > Key: HBASE-16220 > URL: https://issues.apache.org/jira/browse/HBASE-16220 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16220.patch > > > Messages like this can significantly accumulate in regionserver logs when a > cluster is carrying empty tables. > > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > > regionserver.HRegionFileSystem - No StoreFiles for: > > hdfs://pod/hbase/data/default/table/region/family > All this means is no data has been written into a region yet. Table > utilization information can be collected by other means for managing that. > Because many deployments run with DEBUG as the default log level, especially > when trying to track down other production issues, this message is better > logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16217) Identify calling user in ObserverContext
[ https://issues.apache.org/jira/browse/HBASE-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373943#comment-15373943 ] Gary Helmling commented on HBASE-16217: --- Also posted patch on review board: https://reviews.apache.org/r/49970/ > Identify calling user in ObserverContext > > > Key: HBASE-16217 > URL: https://issues.apache.org/jira/browse/HBASE-16217 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Gary Helmling > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16217.master.001.patch > > > We already either explicitly pass down the relevant User instance initiating > an action through the call path, or it is available through > RpcServer.getRequestUser(). We should carry this through in the > ObserverContext for coprocessor upcalls and make use of it for permissions > checking. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16214) Add in UI description of Replication Table
[ https://issues.apache.org/jira/browse/HBASE-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373908#comment-15373908 ] Hudson commented on HBASE-16214: SUCCESS: Integrated in HBase-Trunk_matrix #1217 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1217/]) HBASE-16214 Add in a UI description for the Replication Table (eclark: rev 90ba723dc63571cef14546e9988a76f0adb923aa) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon > Add in UI description of Replication Table > -- > > Key: HBASE-16214 > URL: https://issues.apache.org/jira/browse/HBASE-16214 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16214.patch > > > Add a description for the Replication Table in the HBase UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16092) Procedure v2 - complete child procedure support
[ https://issues.apache.org/jira/browse/HBASE-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373907#comment-15373907 ] Hudson commented on HBASE-16092: SUCCESS: Integrated in HBase-Trunk_matrix #1217 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1217/]) HBASE-16092 Procedure v2 - complete child procedure support (matteo.bertozzi: rev 8cfaa0e72101176f00fa333e6cf6cbea7b2aca44) * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/RootProcedureState.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/NoopProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStoreTracker.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormat.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ProcedureProtos.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/ProcedureExecutor.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStore.java * hbase-protocol/src/main/protobuf/Procedure.proto * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestWALProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestChildProcedures.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestStressWALProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/Procedure.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/ProcedureTestingUtility.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormatReader.java > Procedure v2 - complete child procedure support > --- > > Key: HBASE-16092 > URL: https://issues.apache.org/jira/browse/HBASE-16092 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0, 1.4.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16092-v0.patch, HBASE-16092-v1.patch, > HBASE-16092-v2.patch > > > There was a missing part on the child procedure tracking. > child procedure were never deleted from the wal on parent completion, > leading to failures on startup. (no code uses child procedures yet) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16211) JMXCacheBuster restarting the metrics system might cause tests to hang
[ https://issues.apache.org/jira/browse/HBASE-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373909#comment-15373909 ] Hudson commented on HBASE-16211: SUCCESS: Integrated in HBase-Trunk_matrix #1217 (See [https://builds.apache.org/job/HBase-Trunk_matrix/1217/]) HBASE-16211 JMXCacheBuster restarting the metrics system might cause (enis: rev 6d94925af9d2a3eb2f181d0aa1a875becf258fc8) * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java > JMXCacheBuster restarting the metrics system might cause tests to hang > -- > > Key: HBASE-16211 > URL: https://issues.apache.org/jira/browse/HBASE-16211 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-16211_v1.patch > > > JMXCacheBuster restarts the metrics system. In Phoenix we are manually > injecting a sink to the metric system which gets lost when we restart the > metric system. > See PHOENIX-3062 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16211) JMXCacheBuster restarting the metrics system might cause tests to hang
[ https://issues.apache.org/jira/browse/HBASE-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373887#comment-15373887 ] Hudson commented on HBASE-16211: SUCCESS: Integrated in HBase-1.3-IT #752 (See [https://builds.apache.org/job/HBase-1.3-IT/752/]) HBASE-16211 JMXCacheBuster restarting the metrics system might cause (enis: rev 5bd5f6446660932c9c2ea01d8bd48d1f012b225b) * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java > JMXCacheBuster restarting the metrics system might cause tests to hang > -- > > Key: HBASE-16211 > URL: https://issues.apache.org/jira/browse/HBASE-16211 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-16211_v1.patch > > > JMXCacheBuster restarts the metrics system. In Phoenix we are manually > injecting a sink to the metric system which gets lost when we restart the > metric system. > See PHOENIX-3062 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373854#comment-15373854 ] Sai Teja Ranuva edited comment on HBASE-16210 at 7/12/16 11:01 PM: --- HBASE-16210.master.4.patch : Patch to fix the malicious code warnings in 'findbugs'. was (Author: saitejar): HBASE-16210.master.4.patch : Patch to fix the bugs in the 'findbugs'. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16019) Cut HBase 1.2.2 release
[ https://issues.apache.org/jira/browse/HBASE-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373881#comment-15373881 ] Hudson commented on HBASE-16019: SUCCESS: Integrated in HBase-1.2 #670 (See [https://builds.apache.org/job/HBase-1.2/670/]) HBASE-16019 1.2.2RC2 passed; start 1.2.3-SNAPSHOT. (busbey: rev 244a6ad7df8e03bd10187e03b67d33d0ff381190) * hbase-thrift/pom.xml * hbase-shaded/pom.xml * hbase-procedure/pom.xml * hbase-hadoop2-compat/pom.xml * pom.xml * hbase-annotations/pom.xml * hbase-checkstyle/pom.xml * hbase-client/pom.xml * hbase-assembly/pom.xml * hbase-it/pom.xml * hbase-prefix-tree/pom.xml * hbase-server/pom.xml * hbase-shaded/hbase-shaded-server/pom.xml * hbase-common/pom.xml * hbase-testing-util/pom.xml * hbase-rest/pom.xml * hbase-shell/pom.xml * hbase-external-blockcache/pom.xml * hbase-resource-bundle/pom.xml * hbase-shaded/hbase-shaded-client/pom.xml * hbase-hadoop-compat/pom.xml * hbase-protocol/pom.xml * hbase-examples/pom.xml > Cut HBase 1.2.2 release > --- > > Key: HBASE-16019 > URL: https://issues.apache.org/jira/browse/HBASE-16019 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 1.2.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373854#comment-15373854 ] Sai Teja Ranuva edited comment on HBASE-16210 at 7/12/16 10:50 PM: --- HBASE-16210.master.3.patch : Patch to fix the bugs in the 'findbugs'. was (Author: saitejar): Patch to fix the bugs in the 'findbugs'. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373854#comment-15373854 ] Sai Teja Ranuva edited comment on HBASE-16210 at 7/12/16 10:50 PM: --- HBASE-16210.master.4.patch : Patch to fix the bugs in the 'findbugs'. was (Author: saitejar): HBASE-16210.master.3.patch : Patch to fix the bugs in the 'findbugs'. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Attachment: HBASE-16210.master.4.patch Patch to fix the bugs in the 'findbugs'. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Patch Available (was: Open) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Open (was: Patch Available) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch, HBASE-16210.master.4.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[ https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373850#comment-15373850 ] Matteo Bertozzi commented on HBASE-16220: - +1 > Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE > -- > > Key: HBASE-16220 > URL: https://issues.apache.org/jira/browse/HBASE-16220 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16220.patch > > > Messages like this can significantly accumulate in regionserver logs when a > cluster is carrying empty tables. > > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > > regionserver.HRegionFileSystem - No StoreFiles for: > > hdfs://pod/hbase/data/default/table/region/family > All this means is no data has been written into a region yet. Table > utilization information can be collected by other means for managing that. > Because many deployments run with DEBUG as the default log level, especially > when trying to track down other production issues, this message is better > logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[ https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-16220: --- Status: Patch Available (was: Open) > Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE > -- > > Key: HBASE-16220 > URL: https://issues.apache.org/jira/browse/HBASE-16220 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16220.patch > > > Messages like this can significantly accumulate in regionserver logs when a > cluster is carrying empty tables. > > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > > regionserver.HRegionFileSystem - No StoreFiles for: > > hdfs://pod/hbase/data/default/table/region/family > All this means is no data has been written into a region yet. Table > utilization information can be collected by other means for managing that. > Because many deployments run with DEBUG as the default log level, especially > when trying to track down other production issues, this message is better > logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
[ https://issues.apache.org/jira/browse/HBASE-16220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-16220: --- Attachment: HBASE-16220.patch Also wrap some debug logging with LOG.isDebugEnabled guards in HRegionFileSystem > Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE > -- > > Key: HBASE-16220 > URL: https://issues.apache.org/jira/browse/HBASE-16220 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 2.0.0, 1.4.0, 0.98.21 > > Attachments: HBASE-16220.patch > > > Messages like this can significantly accumulate in regionserver logs when a > cluster is carrying empty tables. > > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > > regionserver.HRegionFileSystem - No StoreFiles for: > > hdfs://pod/hbase/data/default/table/region/family > All this means is no data has been written into a region yet. Table > utilization information can be collected by other means for managing that. > Because many deployments run with DEBUG as the default log level, especially > when trying to track down other production issues, this message is better > logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16220) Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE
Andrew Purtell created HBASE-16220: -- Summary: Demote log level for "HRegionFileSystem - No StoreFiles for" messages to TRACE Key: HBASE-16220 URL: https://issues.apache.org/jira/browse/HBASE-16220 Project: HBase Issue Type: Improvement Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 2.0.0, 1.4.0, 0.98.21 Messages like this can significantly accumulate in regionserver logs when a cluster is carrying empty tables. > 2016-07-07 15:59:59,994 DEBUG [region-location-1] > regionserver.HRegionFileSystem - No StoreFiles for: > hdfs://pod/hbase/data/default/table/region/family All this means is no data has been written into a region yet. Table utilization information can be collected by other means for managing that. Because many deployments run with DEBUG as the default log level, especially when trying to track down other production issues, this message is better logged at TRACE level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16219) Move meta bootstrap out of HMaster
[ https://issues.apache.org/jira/browse/HBASE-16219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-16219: Attachment: HBASE-16219-v0.patch > Move meta bootstrap out of HMaster > -- > > Key: HBASE-16219 > URL: https://issues.apache.org/jira/browse/HBASE-16219 > Project: HBase > Issue Type: Sub-task > Components: master, Region Assignment >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-16219-v0.patch > > > another cleanup to have a smaller integration patch for the new AM. > Trying to isolate the Assignment code from the HMaster. > Move all the bootstrap code to split meta logs and assign meta regions from > HMaster to a MasterMetaBootstrap class to also reduce the long > finishActiveMasterInitialization() method -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16219) Move meta bootstrap out of HMaster
[ https://issues.apache.org/jira/browse/HBASE-16219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-16219: Status: Patch Available (was: Open) > Move meta bootstrap out of HMaster > -- > > Key: HBASE-16219 > URL: https://issues.apache.org/jira/browse/HBASE-16219 > Project: HBase > Issue Type: Sub-task > Components: master, Region Assignment >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-16219-v0.patch > > > another cleanup to have a smaller integration patch for the new AM. > Trying to isolate the Assignment code from the HMaster. > Move all the bootstrap code to split meta logs and assign meta regions from > HMaster to a MasterMetaBootstrap class to also reduce the long > finishActiveMasterInitialization() method -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16217) Identify calling user in ObserverContext
[ https://issues.apache.org/jira/browse/HBASE-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-16217: -- Status: Patch Available (was: Open) The attached patch is a first step in eliminating use of UserGroupInformation.doAs() for permissions checking: * adds a User instance to ObserverContext identifying the calling user for the coprocessor context * updates AccessController to make use of this for permissions checks * eliminates use of UserGroupInformation.doAs() for permissions checks in procedure paths, compactions, splits, region merges > Identify calling user in ObserverContext > > > Key: HBASE-16217 > URL: https://issues.apache.org/jira/browse/HBASE-16217 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Gary Helmling > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16217.master.001.patch > > > We already either explicitly pass down the relevant User instance initiating > an action through the call path, or it is available through > RpcServer.getRequestUser(). We should carry this through in the > ObserverContext for coprocessor upcalls and make use of it for permissions > checking. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16217) Identify calling user in ObserverContext
[ https://issues.apache.org/jira/browse/HBASE-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-16217: -- Attachment: HBASE-16217.master.001.patch > Identify calling user in ObserverContext > > > Key: HBASE-16217 > URL: https://issues.apache.org/jira/browse/HBASE-16217 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Gary Helmling > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16217.master.001.patch > > > We already either explicitly pass down the relevant User instance initiating > an action through the call path, or it is available through > RpcServer.getRequestUser(). We should carry this through in the > ObserverContext for coprocessor upcalls and make use of it for permissions > checking. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[
https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373820#comment-15373820
]
Hadoop QA commented on HBASE-16210:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 28s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 33s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 6s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 23s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 12s
{color} | {color:green} master passed with JDK v1.7.0_80 {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
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 38s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 11s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s {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}
29m 1s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 23s
{color} | {color:red} hbase-common generated 4 new + 0 unchanged - 0 fixed = 4
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 49s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 11s {color}
| {color:red} hbase-common in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 10s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 81m 45s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 146m 40s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-common |
| | Public static org.apache.hadoop.hbase.Timestamp.values() may expose
internal representation by returning Timestamp.values At
Timestamp.java:internal representation by returning Timestamp.values At
[jira] [Commented] (HBASE-16092) Procedure v2 - complete child procedure support
[ https://issues.apache.org/jira/browse/HBASE-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373809#comment-15373809 ] Hudson commented on HBASE-16092: SUCCESS: Integrated in HBase-1.4 #283 (See [https://builds.apache.org/job/HBase-1.4/283/]) HBASE-16092 Procedure v2 - complete child procedure support (matteo.bertozzi: rev 1765988609741a1a341734ed7c3716157f5b111b) * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/ProcedureTestingUtility.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormat.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/Procedure.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/RootProcedureState.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/NoopProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/ProcedureWALFormatReader.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ProcedureProtos.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStoreTracker.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestChildProcedures.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestStressWALProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestWALProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/ProcedureExecutor.java * hbase-protocol/src/main/protobuf/Procedure.proto > Procedure v2 - complete child procedure support > --- > > Key: HBASE-16092 > URL: https://issues.apache.org/jira/browse/HBASE-16092 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0, 1.4.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16092-v0.patch, HBASE-16092-v1.patch, > HBASE-16092-v2.patch > > > There was a missing part on the child procedure tracking. > child procedure were never deleted from the wal on parent completion, > leading to failures on startup. (no code uses child procedures yet) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373583#comment-15373583 ] Sai Teja Ranuva edited comment on HBASE-16210 at 7/12/16 10:14 PM: --- HBASE-16210.master.2.patch - removed the setting of timestamp by the Master(This was causing failure of two unit tests at the client) as we are using only one type of timestamp now. But after HLC is introduced and is made the default timestamp type, the master will have to set the timestamp to default(i.e HLC) if not set by user. This will help transitioning to HLC tables for the newly created tables. was (Author: saitejar): HBASE-16210.master.2.patch - removed the setting of timestamp by the Master(This was causing failure of two unit tests at the client) as only one type of timestamp is present right now. But after HLC is introduced and is the default timestamp type, the master might have to set the timestamp to default(i.e HLC) if not set by user. This will help transitioning to HLC tables for the newly created tables. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14552) Procedure V2 - Reimplement DispatchMergingRegionHandler
[
https://issues.apache.org/jira/browse/HBASE-14552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373796#comment-15373796
]
Hadoop QA commented on HBASE-14552:
---
| (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 30s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 55s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 9s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 14s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 1s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {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 46s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 12s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
33s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 16 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
29m 31s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 15s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 22s
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 0s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 97m 33s {color}
| {color:red} hbase-server in the patch failed. {color} |
|
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Attachment: HBASE-16210.master.3.patch HBASE-16210.master.3.patch : To address the failed tests of Timestamp Class. Info: testCustomClockToString was failing due to the difference in the timezone assumed in the test class and the server timezone. Changed the timezone to UTC to avoid this mismatch. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Patch Available (was: Open) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Open (was: Patch Available) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch, > HBASE-16210.master.3.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16219) Move meta bootstrap out of HMaster
Matteo Bertozzi created HBASE-16219: --- Summary: Move meta bootstrap out of HMaster Key: HBASE-16219 URL: https://issues.apache.org/jira/browse/HBASE-16219 Project: HBase Issue Type: Sub-task Components: master, Region Assignment Affects Versions: 2.0.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Trivial Fix For: 2.0.0 another cleanup to have a smaller integration patch for the new AM. Trying to isolate the Assignment code from the HMaster. Move all the bootstrap code to split meta logs and assign meta regions from HMaster to a MasterMetaBootstrap class to also reduce the long finishActiveMasterInitialization() method -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it
[ https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-16208: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) > Make TableBasedReplicationQueuesImpl check that queue exists before > attempting to remove it > --- > > Key: HBASE-16208 > URL: https://issues.apache.org/jira/browse/HBASE-16208 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph > Fix For: 2.0.0 > > Attachments: HBASE-16208-v1.patch, HBASE-16208-v2.patch, > HBASE-16208.patch > > > Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId) > will cause it to delete the row with the given queue id. Yet this row is not > created until the first log is registered for the queue. This causes the > server to abort if we every try to remove a queue that has not had a log > registered to it yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15335) Add composite key support in row key
[
https://issues.apache.org/jira/browse/HBASE-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373777#comment-15373777
]
Hadoop QA commented on HBASE-15335:
---
| (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
1s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 20s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 34s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 19s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
39s {color} | {color:green} master passed {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} cc {color} | {color:green} 1m 24s
{color} | {color:green} the patch passed {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} scalac {color} | {color:green} 1m 24s
{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.7.0_80 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 24s
{color} | {color:green} the patch passed {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} scalac {color} | {color:green} 1m 24s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {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}
33m 7s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 16s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} scaladoc {color} | {color:red} 1m 55s
{color} | {color:red} hbase-spark generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
31s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} scaladoc {color} | {color:red} 2m 25s
[jira] [Created] (HBASE-16218) Eliminate use of UGI.doAs() in AccessController testing
Gary Helmling created HBASE-16218: - Summary: Eliminate use of UGI.doAs() in AccessController testing Key: HBASE-16218 URL: https://issues.apache.org/jira/browse/HBASE-16218 Project: HBase Issue Type: Sub-task Components: security Reporter: Gary Helmling Assignee: Gary Helmling Many tests for AccessController observer coprocessor hooks make use of UGI.doAs() when the test user could simply be passed through. Eliminate the unnecessary use of doAs(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16215) clean up 1.0.z references
[ https://issues.apache.org/jira/browse/HBASE-16215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373768#comment-15373768 ] Sean Busbey commented on HBASE-16215: - well, I disagree that there's no overhead. the list of branches could be where folks can look to see the work that is going on. ATM they have to rely on recently changed sorting to gauge where work is actually happening. keeping history is good, and I like the archive/foo naming. How about tags? that would mirror our use of 'rel/foo' tags for releases. Then if someone decides to drive an additional release out of one of those release lines it'd be easy enough to start a branch off of e.g. an 'archive/branch-1.0' tag. (or maybe 'archive/eom-1.0' so the word branch isn't there?) I'll start a DISCUSS thread. I think we're close enough to agreement to make progress, so we might as well get everyone talking about it now. > clean up 1.0.z references > - > > Key: HBASE-16215 > URL: https://issues.apache.org/jira/browse/HBASE-16215 > Project: HBase > Issue Type: Task > Components: community, website >Reporter: Sean Busbey > > I've seen us state a few places that 1.0.z is EOM. We should clean up > remaining references > * remove 1.0.z artifact from dist.apache > * remove it from the ref guide (java prereqs, hadoop prereqs, RM list) > * remove branch-1.0 from git > * remove unreleased 1.0.z versions from JIRA > * archive released 1.0.z versions in JIRA -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16217) Identify calling user in ObserverContext
Gary Helmling created HBASE-16217: - Summary: Identify calling user in ObserverContext Key: HBASE-16217 URL: https://issues.apache.org/jira/browse/HBASE-16217 Project: HBase Issue Type: Sub-task Components: Coprocessors, security Reporter: Gary Helmling Assignee: Gary Helmling We already either explicitly pass down the relevant User instance initiating an action through the call path, or it is available through RpcServer.getRequestUser(). We should carry this through in the ObserverContext for coprocessor upcalls and make use of it for permissions checking. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it
[ https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373765#comment-15373765 ] Elliott Clark commented on HBASE-16208: --- +1 > Make TableBasedReplicationQueuesImpl check that queue exists before > attempting to remove it > --- > > Key: HBASE-16208 > URL: https://issues.apache.org/jira/browse/HBASE-16208 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph > Attachments: HBASE-16208-v1.patch, HBASE-16208-v2.patch, > HBASE-16208.patch > > > Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId) > will cause it to delete the row with the given queue id. Yet this row is not > created until the first log is registered for the queue. This causes the > server to abort if we every try to remove a queue that has not had a log > registered to it yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it
[
https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373762#comment-15373762
]
Hadoop QA commented on HBASE-16208:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 23s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 12s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 58s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
33s {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} 0m 55s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 16s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 55s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s {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}
29m 13s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 3s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 151m 20s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 206m 27s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12817479/HBASE-16208-v1.patch |
| JIRA Issue | HBASE-16208 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency
[jira] [Commented] (HBASE-16215) clean up 1.0.z references
[ https://issues.apache.org/jira/browse/HBASE-16215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373754#comment-15373754 ] Enis Soztutar commented on HBASE-16215: --- bq. we delete some old branches from the repo, mostly at the moment it appears to be feature branches that get merged. we should be cleaning up more, but I'm happy to start a DISCUSS thread if folks want to go over relative merits of keeping vs cleaning up. I don't remember deleting a "release" branch at all. Feature branches should be fine, since we don't need to keep history there. There is no overhead of having branches, so if we are doing anything, we should rename branches under archive/branch-1.0 or something to differentiate, but never delete release branches. > clean up 1.0.z references > - > > Key: HBASE-16215 > URL: https://issues.apache.org/jira/browse/HBASE-16215 > Project: HBase > Issue Type: Task > Components: community, website >Reporter: Sean Busbey > > I've seen us state a few places that 1.0.z is EOM. We should clean up > remaining references > * remove 1.0.z artifact from dist.apache > * remove it from the ref guide (java prereqs, hadoop prereqs, RM list) > * remove branch-1.0 from git > * remove unreleased 1.0.z versions from JIRA > * archive released 1.0.z versions in JIRA -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16169) Make RegionSizeCalculator scalable
[ https://issues.apache.org/jira/browse/HBASE-16169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvel Thirumoolan updated HBASE-16169: - Attachment: HBASE-16169.master.002.patch > Make RegionSizeCalculator scalable > -- > > Key: HBASE-16169 > URL: https://issues.apache.org/jira/browse/HBASE-16169 > Project: HBase > Issue Type: Sub-task > Components: mapreduce, scaling >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16169.master.000.patch, > HBASE-16169.master.001.patch, HBASE-16169.master.002.patch > > > RegionSizeCalculator is needed for better split generation of MR jobs. This > requires RegionLoad which can be obtained via ClusterStatus, i.e. accessing > Master. We don't want master to be in this path. > The proposal is to add an API to the RegionServer that gets RegionLoad of all > regions hosted on it or those of a table if specified. RegionSizeCalculator > can use the latter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16215) clean up 1.0.z references
[
https://issues.apache.org/jira/browse/HBASE-16215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373724#comment-15373724
]
Sean Busbey commented on HBASE-16215:
-
{quote}
bq. remove branch-1.0 from git
We should keep the branch in git. We do not delete old branches from repo.
{quote}
having it in git leaves the matter of wether folks should be pulling back
changes ambiguous. if there are no more planned releases, we should nix the
branch so that we don't end up with inconsistent backports (like we have now).
we delete some old branches from the repo, mostly at the moment it appears to
be feature branches that get merged. we should be cleaning up more, but I'm
happy to start a DISCUSS thread if folks want to go over relative merits of
keeping vs cleaning up.
{quote}
bq. remove unreleased 1.0.z versions from JIRA
Why? There are still some issues committed to branch-1.0, but not released. In
the off-chance that some release will happen, I would opt for keeping history.
{quote}
Similar to the branch, it leaves ambiguous wether or not we as a project expect
fixes to target them. To maintain history, I think we can archive an unreleased
version. That would mean archiving 1.0.4 and deleting 1.0.5 (since nothing
should be in the later).
{quote}
bq. archive released 1.0.z versions in JIRA
It seems that we have only archived a very small number of versions so far. We
need a big cleanup.
{quote}
yep. :) I figured I'd keep this scoped to a particular release line and fix the
other stuff later.
> clean up 1.0.z references
> -
>
> Key: HBASE-16215
> URL: https://issues.apache.org/jira/browse/HBASE-16215
> Project: HBase
> Issue Type: Task
> Components: community, website
>Reporter: Sean Busbey
>
> I've seen us state a few places that 1.0.z is EOM. We should clean up
> remaining references
> * remove 1.0.z artifact from dist.apache
> * remove it from the ref guide (java prereqs, hadoop prereqs, RM list)
> * remove branch-1.0 from git
> * remove unreleased 1.0.z versions from JIRA
> * archive released 1.0.z versions in JIRA
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16211) JMXCacheBuster restarting the metrics system might cause tests to hang
[ https://issues.apache.org/jira/browse/HBASE-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-16211: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to 1.3+. Thanks Josh for taking a look. > JMXCacheBuster restarting the metrics system might cause tests to hang > -- > > Key: HBASE-16211 > URL: https://issues.apache.org/jira/browse/HBASE-16211 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-16211_v1.patch > > > JMXCacheBuster restarts the metrics system. In Phoenix we are manually > injecting a sink to the metric system which gets lost when we restart the > metric system. > See PHOENIX-3062 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15643) Need metrics of cache hit ratio, etc for one table
[ https://issues.apache.org/jira/browse/HBASE-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373693#comment-15373693 ] Enis Soztutar commented on HBASE-15643: --- Agreed. [~aliciashu] did some experiments with ycsb loading, and there was a perf hit about 3% of so. We were discussing offline about a way to carry the metrics reference in the HRegion itself where it is initialized once per region lifecycle, and pass it down to the HFileBlockKey to get rid of the map lookup. I think she will prototype the approach to see whether it works or not. > Need metrics of cache hit ratio, etc for one table > -- > > Key: HBASE-15643 > URL: https://issues.apache.org/jira/browse/HBASE-15643 > Project: HBase > Issue Type: Improvement >Reporter: Heng Chen >Assignee: Alicia Ying Shu > Attachments: HBASE-15643.patch > > > There are many tables on our cluster, only some of them need to be read > online. > We could improve the performance of read by cache, but we need some metrics > for it at table level. There are a few we can collect: BlockCacheCount, > BlockCacheSize, BlockCacheHitCount, BlockCacheMissCount, BlockCacheHitPercent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16208) Make TableBasedReplicationQueuesImpl check that queue exists before attempting to remove it
[
https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373686#comment-15373686
]
Hadoop QA commented on HBASE-16208:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 21s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 8s
{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_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s {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:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} master passed with JDK v1.7.0_80 {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
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s {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}
26m 40s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 1s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 103m 45s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 153m 43s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
| | hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
| | hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestReplicasClient |
| | org.apache.hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
| | org.apache.hadoop.hbase.client.TestBlockEvictionFromClient |
\\
[jira] [Updated] (HBASE-15335) Add composite key support in row key
[ https://issues.apache.org/jira/browse/HBASE-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-15335: --- Attachment: HBASE-15335-8.patch > Add composite key support in row key > > > Key: HBASE-15335 > URL: https://issues.apache.org/jira/browse/HBASE-15335 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-15335-1.patch, HBASE-15335-2.patch, > HBASE-15335-3.patch, HBASE-15335-4.patch, HBASE-15335-5.patch, > HBASE-15335-6.patch, HBASE-15335-7.patch, HBASE-15335-8.patch > > > Add composite key filter support in the connector. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16215) clean up 1.0.z references
[ https://issues.apache.org/jira/browse/HBASE-16215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373643#comment-15373643 ] Enis Soztutar commented on HBASE-16215: --- bq. remove 1.0.z artifact from dist.apache This is fine. It should be in archive anyway if anybody wants to download. bq. remove branch-1.0 from git We should keep the branch in git. We do not delete old branches from repo. bq. remove unreleased 1.0.z versions from JIRA Why? There are still some issues committed to branch-1.0, but not released. In the off-chance that some release will happen, I would opt for keeping history. bq. archive released 1.0.z versions in JIRA It seems that we have only archived a very small number of versions so far. We need a big cleanup. > clean up 1.0.z references > - > > Key: HBASE-16215 > URL: https://issues.apache.org/jira/browse/HBASE-16215 > Project: HBase > Issue Type: Task > Components: community, website >Reporter: Sean Busbey > > I've seen us state a few places that 1.0.z is EOM. We should clean up > remaining references > * remove 1.0.z artifact from dist.apache > * remove it from the ref guide (java prereqs, hadoop prereqs, RM list) > * remove branch-1.0 from git > * remove unreleased 1.0.z versions from JIRA > * archive released 1.0.z versions in JIRA -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-16216) Clean up Cell source code.
[ https://issues.apache.org/jira/browse/HBASE-16216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark resolved HBASE-16216. --- Resolution: Fixed > Clean up Cell source code. > -- > > Key: HBASE-16216 > URL: https://issues.apache.org/jira/browse/HBASE-16216 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-16216.patch > > > formatting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16214) Add in UI description of Replication Table
[ https://issues.apache.org/jira/browse/HBASE-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-16214: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Pushed to master. > Add in UI description of Replication Table > -- > > Key: HBASE-16214 > URL: https://issues.apache.org/jira/browse/HBASE-16214 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16214.patch > > > Add a description for the Replication Table in the HBase UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16216) Clean up Cell source code.
[ https://issues.apache.org/jira/browse/HBASE-16216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-16216: -- Attachment: HBASE-16216.patch > Clean up Cell source code. > -- > > Key: HBASE-16216 > URL: https://issues.apache.org/jira/browse/HBASE-16216 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-16216.patch > > > formatting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-16216) Clean up Cell source code.
Elliott Clark created HBASE-16216: - Summary: Clean up Cell source code. Key: HBASE-16216 URL: https://issues.apache.org/jira/browse/HBASE-16216 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Assignee: Elliott Clark formatting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16052) Improve HBaseFsck Scalability
[ https://issues.apache.org/jira/browse/HBASE-16052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Lau updated HBASE-16052: Attachment: HBASE-16052-v3-0.98.patch Attached patch for 0.98. Let me know if this looks good [~te...@apache.org] and [~syuanjiang]. > Improve HBaseFsck Scalability > - > > Key: HBASE-16052 > URL: https://issues.apache.org/jira/browse/HBASE-16052 > Project: HBase > Issue Type: Improvement > Components: hbck >Reporter: Ben Lau >Assignee: Ben Lau > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16052-master.patch, HBASE-16052-v3-0.98.patch, > HBASE-16052-v3-branch-1.patch, HBASE-16052-v3-master.patch > > > There are some problems with HBaseFsck that make it unnecessarily slow > especially for large tables or clusters with many regions. > This patch tries to fix the biggest bottlenecks and also include a couple of > bug fixes for some of the race conditions caused by gathering and holding > state about a live cluster that is no longer true by the time you use that > state in Fsck processing. These race conditions cause Fsck to crash and > become unusable on large clusters with lots of region splits/merges. > Here are some scalability/performance problems in HBaseFsck and the changes > the patch makes: > - Unnecessary I/O and RPCs caused by fetching an array of FileStatuses and > then discarding everything but the Paths, then passing the Paths to a > PathFilter, and then having the filter look up the (previously discarded) > FileStatuses of the paths again. This is actually worse than double I/O > because the first lookup obtains a batch of FileStatuses while all the other > lookups are individual RPCs performed sequentially. > -- Avoid this by adding a FileStatusFilter so that filtering can happen > directly on FileStatuses > -- This performance bug affects more than Fsck, but also to some extent > things like snapshots, hfile archival, etc. I didn't have time to look too > deep into other things affected and didn't want to increase the scope of this > ticket so I focus mostly on Fsck and make only a few improvements to other > codepaths. The changes in this patch though should make it fairly easy to > fix other code paths in later jiras if we feel there are some other features > strongly impacted by this problem. > - OfflineReferenceFileRepair is the most expensive part of Fsck (often 50% of > Fsck runtime) and the running time scales with the number of store files, yet > the function is completely serial > -- Make offlineReferenceFileRepair multithreaded > - LoadHdfsRegionDirs() uses table-level concurrency, which is a big > bottleneck if you have 1 large cluster with 1 very large table that has > nearly all the regions > -- Change loadHdfsRegionDirs() to region-level parallelism instead of > table-level parallelism for operations. > The changes benefit all clusters but are especially noticeable for large > clusters with a few very large tables. On our version of 0.98 with the > original patch we had a moderately sized production cluster with 2 (user) > tables and ~160k regions where HBaseFsck went from taking 18 min to 5 minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Patch Available (was: Open) HBASE-16210.master.2.patch - removed the setting of timestamp by the Master(This was causing failure of two unit tests at the client) as only one type of timestamp is present right now. But after HLC is introduced and is the default timestamp type, the master might have to set the timestamp to default(i.e HLC) if not set by user. This will help transitioning to HLC tables for the newly created tables. > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16019) Cut HBase 1.2.2 release
[ https://issues.apache.org/jira/browse/HBASE-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373580#comment-15373580 ] Hudson commented on HBASE-16019: SUCCESS: Integrated in HBase-1.2-IT #551 (See [https://builds.apache.org/job/HBase-1.2-IT/551/]) HBASE-16019 1.2.2RC2 passed; start 1.2.3-SNAPSHOT. (busbey: rev 244a6ad7df8e03bd10187e03b67d33d0ff381190) * hbase-resource-bundle/pom.xml * hbase-procedure/pom.xml * hbase-shell/pom.xml * pom.xml * hbase-it/pom.xml * hbase-annotations/pom.xml * hbase-protocol/pom.xml * hbase-rest/pom.xml * hbase-server/pom.xml * hbase-external-blockcache/pom.xml * hbase-assembly/pom.xml * hbase-shaded/hbase-shaded-server/pom.xml * hbase-testing-util/pom.xml * hbase-checkstyle/pom.xml * hbase-hadoop-compat/pom.xml * hbase-hadoop2-compat/pom.xml * hbase-shaded/pom.xml * hbase-client/pom.xml * hbase-common/pom.xml * hbase-thrift/pom.xml * hbase-shaded/hbase-shaded-client/pom.xml * hbase-examples/pom.xml * hbase-prefix-tree/pom.xml > Cut HBase 1.2.2 release > --- > > Key: HBASE-16019 > URL: https://issues.apache.org/jira/browse/HBASE-16019 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 1.2.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16207) can't restore snapshot without "Admin" permission
[
https://issues.apache.org/jira/browse/HBASE-16207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373560#comment-15373560
]
Hudson commented on HBASE-16207:
SUCCESS: Integrated in HBase-1.2 #669 (See
[https://builds.apache.org/job/HBase-1.2/669/])
HBASE-16207 can't restore snapshot without "Admin" permission (matteo.bertozzi:
rev 9b5f19eaebfb6099de9edd1204be7da9fc4c6a34)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
> can't restore snapshot without "Admin" permission
> -
>
> Key: HBASE-16207
> URL: https://issues.apache.org/jira/browse/HBASE-16207
> Project: HBase
> Issue Type: Bug
> Components: master, snapshots
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.1.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0, 1.1.6, 1.3.1, 0.98.21, 1.2.3
>
> Attachments: HBASE-16207-v0.patch, HBASE-16207-v0_branch-1.patch
>
>
> MasterRpcServices.restoreSnapshot() tries to verify if the NS exists before
> starting the restore, but instead of calling ensureNamespaceExists() it calls
> master.getNamespace() which requires ADMIN permission to get the NS
> descriptor.
> {code}
> public RestoreSnapshotResponse restoreSnapshot(RpcController controller,
> ...
> // Ensure namespace exists. Will throw exception if non-known NS.
> master.getNamespace(dstTable.getNamespaceAsString());
> {code}
> unfortunately i'm not aware of any unit-test that cover this kind of
> situations. we cover single ACLs from the TestAccessController but we don't
> exercise rpc calls and verify if there is more than one check on the ACLs
> like in this case
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Status: Open (was: Patch Available) > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16210) Add Timestamp class to the hbase-common and Timestamp type to HTable.
[ https://issues.apache.org/jira/browse/HBASE-16210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Teja Ranuva updated HBASE-16210: Attachment: HBASE-16210.master.2.patch > Add Timestamp class to the hbase-common and Timestamp type to HTable. > - > > Key: HBASE-16210 > URL: https://issues.apache.org/jira/browse/HBASE-16210 > Project: HBase > Issue Type: Sub-task >Reporter: Sai Teja Ranuva >Assignee: Sai Teja Ranuva >Priority: Minor > Labels: patch, testing > Attachments: HBASE-16210.master.1.patch, HBASE-16210.master.2.patch > > > This is a sub-issue of > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070]. This JIRA is > a small step towards completely adding Hybrid Logical Clocks(HLC) to HBase. > The main idea of HLC is described in > [HBase-14070|https://issues.apache.org/jira/browse/HBASE-14070] along with > the motivation of adding it to HBase. > What is this patch/issue about ? > This issue attempts to add a timestamp class to hbase-common and timestamp > type to HTable. > This is a part of the attempt to get HLC into HBase. This patch does not > interfere with the current working of HBase. > Why Timestamp Class ? > Timestamp class can be as an abstraction to represent time in Hbase in 64 > bits. > It is just used for manipulating with the 64 bits of the timestamp and is not > concerned about the actual time. > There are three types of timestamps. System time, Custom and HLC. Each one of > it has methods to manipulate the 64 bits of timestamp. > HTable changes: Added a timestamp type property to HTable. This will help > HBase exist in conjunction with old type of timestamp and also the HLC which > will be introduced. The default is set to custom timestamp(current way of > usage of timestamp). default unset timestamp is also custom timestamp as it > should be so. The default timestamp will be changed to HLC when HLC feature > is introduced completely in HBase. > Suggestions are welcome. > [~enis] - The timestamp class is the one written by you, I have not made any > changes. I just changed the default timestamp of the table to Custom. > [~j...@cloudera.com], [~stack] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16019) Cut HBase 1.2.2 release
[ https://issues.apache.org/jira/browse/HBASE-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373554#comment-15373554 ] Sean Busbey commented on HBASE-16019: - * 1.2.2 RC2 passed * pushed to dist. * published nexus * closed jira version * updated branch-1.2 to next SNAPSHOT > Cut HBase 1.2.2 release > --- > > Key: HBASE-16019 > URL: https://issues.apache.org/jira/browse/HBASE-16019 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 1.2.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16150) Remove ConcurrentIndex
[ https://issues.apache.org/jira/browse/HBASE-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-16150: Fix Version/s: 1.4.0 1.3.0 2.0.0 > Remove ConcurrentIndex > -- > > Key: HBASE-16150 > URL: https://issues.apache.org/jira/browse/HBASE-16150 > Project: HBase > Issue Type: Bug >Reporter: Hiroshi Ikeda >Assignee: Hiroshi Ikeda > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-16150-branch-1.patch, HBASE-16150-master.patch, > remove_index.png > > > ConcurrentIndex has race condition and it is enough to use > ConcurrentSkipListSet instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16207) can't restore snapshot without "Admin" permission
[
https://issues.apache.org/jira/browse/HBASE-16207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373551#comment-15373551
]
Hudson commented on HBASE-16207:
FAILURE: Integrated in HBase-Trunk_matrix #1216 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1216/])
HBASE-16207 can't restore snapshot without "Admin" permission (matteo.bertozzi:
rev 2650711e944244b3b87e6d6805b7716b216e8786)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java
> can't restore snapshot without "Admin" permission
> -
>
> Key: HBASE-16207
> URL: https://issues.apache.org/jira/browse/HBASE-16207
> Project: HBase
> Issue Type: Bug
> Components: master, snapshots
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.1.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0, 1.1.6, 1.3.1, 0.98.21, 1.2.3
>
> Attachments: HBASE-16207-v0.patch, HBASE-16207-v0_branch-1.patch
>
>
> MasterRpcServices.restoreSnapshot() tries to verify if the NS exists before
> starting the restore, but instead of calling ensureNamespaceExists() it calls
> master.getNamespace() which requires ADMIN permission to get the NS
> descriptor.
> {code}
> public RestoreSnapshotResponse restoreSnapshot(RpcController controller,
> ...
> // Ensure namespace exists. Will throw exception if non-known NS.
> master.getNamespace(dstTable.getNamespaceAsString());
> {code}
> unfortunately i'm not aware of any unit-test that cover this kind of
> situations. we cover single ACLs from the TestAccessController but we don't
> exercise rpc calls and verify if there is more than one check on the ACLs
> like in this case
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16150) Remove ConcurrentIndex
[ https://issues.apache.org/jira/browse/HBASE-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-16150: Resolution: Fixed Status: Resolved (was: Patch Available) marking as resolved > Remove ConcurrentIndex > -- > > Key: HBASE-16150 > URL: https://issues.apache.org/jira/browse/HBASE-16150 > Project: HBase > Issue Type: Bug >Reporter: Hiroshi Ikeda >Assignee: Hiroshi Ikeda > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-16150-branch-1.patch, HBASE-16150-master.patch, > remove_index.png > > > ConcurrentIndex has race condition and it is enough to use > ConcurrentSkipListSet instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16207) can't restore snapshot without "Admin" permission
[
https://issues.apache.org/jira/browse/HBASE-16207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-16207:
Fix Version/s: (was: 1.2.2)
1.2.3
> can't restore snapshot without "Admin" permission
> -
>
> Key: HBASE-16207
> URL: https://issues.apache.org/jira/browse/HBASE-16207
> Project: HBase
> Issue Type: Bug
> Components: master, snapshots
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.1.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0, 1.1.6, 1.3.1, 0.98.21, 1.2.3
>
> Attachments: HBASE-16207-v0.patch, HBASE-16207-v0_branch-1.patch
>
>
> MasterRpcServices.restoreSnapshot() tries to verify if the NS exists before
> starting the restore, but instead of calling ensureNamespaceExists() it calls
> master.getNamespace() which requires ADMIN permission to get the NS
> descriptor.
> {code}
> public RestoreSnapshotResponse restoreSnapshot(RpcController controller,
> ...
> // Ensure namespace exists. Will throw exception if non-known NS.
> master.getNamespace(dstTable.getNamespaceAsString());
> {code}
> unfortunately i'm not aware of any unit-test that cover this kind of
> situations. we cover single ACLs from the TestAccessController but we don't
> exercise rpc calls and verify if there is more than one check on the ACLs
> like in this case
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16201) NPE in RpcServer causing intermittent UT failure of TestMasterReplication#testHFileCyclicReplication
[
https://issues.apache.org/jira/browse/HBASE-16201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-16201:
Fix Version/s: (was: 1.2.2)
1.2.3
> NPE in RpcServer causing intermittent UT failure of
> TestMasterReplication#testHFileCyclicReplication
>
>
> Key: HBASE-16201
> URL: https://issues.apache.org/jira/browse/HBASE-16201
> Project: HBase
> Issue Type: Bug
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0, 1.1.6, 1.2.3
>
> Attachments: HBASE-16201.patch
>
>
> Every several rounds of {{TestMasterReplication#testHFileCyclicReplication}},
> we could observe below NPE in UT log:
> {noformat}
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2257)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:118)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:189)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:169)
> {noformat}
> And related codes at RpcServer line 2257 are:
> {code}
> if (e instanceof ServiceException) {
> e = e.getCause();
> }
> // increment the number of requests that were exceptions.
> metrics.exception(e);
> if (e instanceof LinkageError) throw new DoNotRetryIOException(e);
> if (e instanceof IOException) throw (IOException)e;
> {code}
> And after some debugging, we could find several places that constructing
> ServiceException with no cause, such as in
> {{RsRpcServices#replicateWALEntry}}:
> {code}
> if (regionServer.replicationSinkHandler != null) {
> ...
> } else {
> throw new ServiceException("Replication services are not initialized
> yet");
> }
> {code}
> So we should firstly check and only reset {{e=e.getCause()}} when the cause
> is not null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16132) Scan does not return all the result when regionserver is busy
[
https://issues.apache.org/jira/browse/HBASE-16132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-16132:
Fix Version/s: (was: 1.2.2)
1.2.3
> Scan does not return all the result when regionserver is busy
> -
>
> Key: HBASE-16132
> URL: https://issues.apache.org/jira/browse/HBASE-16132
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: binlijin
>Assignee: binlijin
> Fix For: 2.0.0, 1.3.0, 1.1.6, 1.2.3
>
> Attachments: HBASE-16132.patch, HBASE-16132_v2.patch,
> HBASE-16132_v3.patch, HBASE-16132_v3.patch, TestScanMissingData.java
>
>
> We have find some corner case, when regionserver is busy and last a long
> time. Some scanner may return null even if they do not scan all data.
> We find in ScannerCallableWithReplicas there is a case do not handler
> correct, when cs.poll timeout and do not return any result , it is will
> return a null result, so scan get null result, and end the scan.
> {code}
> try {
> Future> f = cs.poll(timeout,
> TimeUnit.MILLISECONDS);
> if (f != null) {
> Pair r = f.get(timeout,
> TimeUnit.MILLISECONDS);
> if (r != null && r.getSecond() != null) {
> updateCurrentlyServingReplica(r.getSecond(), r.getFirst(), done,
> pool);
> }
> return r == null ? null : r.getFirst(); // great we got an answer
> }
> } catch (ExecutionException e) {
> RpcRetryingCallerWithReadReplicas.throwEnrichedException(e, retries);
> } catch (CancellationException e) {
> throw new InterruptedIOException(e.getMessage());
> } catch (InterruptedException e) {
> throw new InterruptedIOException(e.getMessage());
> } catch (TimeoutException e) {
> throw new InterruptedIOException(e.getMessage());
> } finally {
> // We get there because we were interrupted or because one or more of
> the
> // calls succeeded or failed. In all case, we stop all our tasks.
> cs.cancelAll();
> }
> return null; // unreachable
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16068) Procedure v2 - use consts for conf properties in tests
[
https://issues.apache.org/jira/browse/HBASE-16068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Antonov updated HBASE-16068:
Fix Version/s: (was: 1.3.1)
1.3.0
> Procedure v2 - use consts for conf properties in tests
> ---
>
> Key: HBASE-16068
> URL: https://issues.apache.org/jira/browse/HBASE-16068
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2, test
>Affects Versions: 2.0.0, 1.3.0, 1.2.1
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Trivial
> Fix For: 2.0.0, 1.3.0, 1.2.2
>
> Attachments: HBASE-16068-v0.patch
>
>
> replace the hardcoded properties string conf.set("foo.key", v) in the tests
> with the use of the configuration property constants that we already have
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16214) Add in UI description of Replication Table
[ https://issues.apache.org/jira/browse/HBASE-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373510#comment-15373510 ] Elliott Clark commented on HBASE-16214: --- +1 > Add in UI description of Replication Table > -- > > Key: HBASE-16214 > URL: https://issues.apache.org/jira/browse/HBASE-16214 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph >Priority: Minor > Attachments: HBASE-16214.patch > > > Add a description for the Replication Table in the HBase UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14552) Procedure V2 - Reimplement DispatchMergingRegionHandler
[ https://issues.apache.org/jira/browse/HBASE-14552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-14552: --- Attachment: HBASE-14552.v1-master.patch > Procedure V2 - Reimplement DispatchMergingRegionHandler > --- > > Key: HBASE-14552 > URL: https://issues.apache.org/jira/browse/HBASE-14552 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Stephen Yuan Jiang > Attachments: HBASE-14552.v0-master.patch, HBASE-14552.v1-master.patch > > > use the proc-v2 state machine for DispatchMergingRegionHandler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16214) Add in UI description of Replication Table
[
https://issues.apache.org/jira/browse/HBASE-16214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373479#comment-15373479
]
Hadoop QA commented on HBASE-16214:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 41s
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {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}
29m 18s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 97m 50s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 134m 48s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12817466/HBASE-16214.patch |
| JIRA Issue | HBASE-16214 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 2650711 |
| Default Java | 1.7.0_80 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/JDK_1.7_latest_:1.7.0_80 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/2607/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/2607/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> Add in UI description of Replication Table
> --
>
> Key: HBASE-16214
> URL: https://issues.apache.org/jira/browse/HBASE-16214
> Project: HBase
> Issue Type: Sub-task
> Components: Replication
>Reporter: Joseph
>Assignee: Joseph
>Priority: Minor
> Attachments: HBASE-16214.patch
>
>
> Add a description for the Replication Table in the HBase UI
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16215) clean up 1.0.z references
[ https://issues.apache.org/jira/browse/HBASE-16215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373472#comment-15373472 ] Sean Busbey commented on HBASE-16215: - also update teh dist directory HEADER.html to mark it EOL. > clean up 1.0.z references > - > > Key: HBASE-16215 > URL: https://issues.apache.org/jira/browse/HBASE-16215 > Project: HBase > Issue Type: Task > Components: community, website >Reporter: Sean Busbey > > I've seen us state a few places that 1.0.z is EOM. We should clean up > remaining references > * remove 1.0.z artifact from dist.apache > * remove it from the ref guide (java prereqs, hadoop prereqs, RM list) > * remove branch-1.0 from git > * remove unreleased 1.0.z versions from JIRA > * archive released 1.0.z versions in JIRA -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14552) Procedure V2 - Reimplement DispatchMergingRegionHandler
[ https://issues.apache.org/jira/browse/HBASE-14552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-14552: --- Attachment: (was: HBASE-14552.v1-master.patch) > Procedure V2 - Reimplement DispatchMergingRegionHandler > --- > > Key: HBASE-14552 > URL: https://issues.apache.org/jira/browse/HBASE-14552 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Stephen Yuan Jiang > Attachments: HBASE-14552.v0-master.patch > > > use the proc-v2 state machine for DispatchMergingRegionHandler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14552) Procedure V2 - Reimplement DispatchMergingRegionHandler
[ https://issues.apache.org/jira/browse/HBASE-14552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-14552: --- Attachment: HBASE-14552.v1-master.patch > Procedure V2 - Reimplement DispatchMergingRegionHandler > --- > > Key: HBASE-14552 > URL: https://issues.apache.org/jira/browse/HBASE-14552 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Stephen Yuan Jiang > Attachments: HBASE-14552.v0-master.patch, HBASE-14552.v1-master.patch > > > use the proc-v2 state machine for DispatchMergingRegionHandler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16209) Retry opening a region in AssignmentManager if RPC fails
[ https://issues.apache.org/jira/browse/HBASE-16209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph updated HBASE-16209: --- Description: (was: Currently AssignmentManager.assign(RegionState state, boolean forceNewPlan) returns immediately after calling serverManager.sendRegionOpen(plan.getDestination(), region, favoredNodes). It never checks the returned RegionOpeningState for success. We should retry if this occurs.) > Retry opening a region in AssignmentManager if RPC fails > > > Key: HBASE-16209 > URL: https://issues.apache.org/jira/browse/HBASE-16209 > Project: HBase > Issue Type: Bug >Reporter: Joseph >Assignee: Joseph > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16211) JMXCacheBuster restarting the metrics system might cause tests to hang
[ https://issues.apache.org/jira/browse/HBASE-16211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373423#comment-15373423 ] Josh Elser commented on HBASE-16211: LGTM, [~enis]. Simple enough of a change. > JMXCacheBuster restarting the metrics system might cause tests to hang > -- > > Key: HBASE-16211 > URL: https://issues.apache.org/jira/browse/HBASE-16211 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-16211_v1.patch > > > JMXCacheBuster restarts the metrics system. In Phoenix we are manually > injecting a sink to the metric system which gets lost when we restart the > metric system. > See PHOENIX-3062 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
