[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741507#comment-16741507
]
Alston Williams commented on HBASE-21504:
-
I'm so sorry that I can't attach my patch in the comment. So I print it here:
{code:java}
diff --git
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/TimeRangeTracker.java
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/TimeRangeTracker.java
index 5c0eee5..9c0ab9f 100644
---
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/TimeRangeTracker.java
+++
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/TimeRangeTracker.java
@@ -226,7 +226,7 @@ public abstract class TimeRangeTracker {
min = TimeRange.INITIAL_MIN_TIMESTAMP;
}
if (max == INITIAL_MAX_TIMESTAMP) {
- max = TimeRange.INITIAL_MAX_TIMESTAMP;
+ max = min;
}
return new TimeRange(min, max);
}
{code}
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.9, 2.1.2, 1.2.10, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741505#comment-16741505 ] Alston Williams commented on HBASE-21504: - Hello, I have tested this issue, and looked at the solution. But I think there is a better solution. Actually, this issue is caused by, the HStoreFile's max timestamp is Long.MAX_VALUE if it is empty. And I think it is unreasonable. I think it is more reasonable to set HStoreFile's max timestamp to it's min timestamp if max timestamp is not present. And based on this solution, I export a patch. I have also tested it by the unit test provided by author. Thanks if you can give it a look. > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Assignee: Zheng Hu >Priority: Critical > Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.9, 2.1.2, 1.2.10, 2.0.4 > > Attachments: 1.patch, HBASE-21504.v1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722083#comment-16722083
]
Hudson commented on HBASE-21504:
Results for branch branch-1.3
[build #578 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/578/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/578//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/578//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/578//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721892#comment-16721892 ] Hudson commented on HBASE-21504: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #512 (See [https://builds.apache.org/job/HBase-1.3-IT/512/]) Revert "HBASE-21504 If enable FIFOCompactionPolicy, a compaction may (apurtell: rev d2c1deef1c1dd858fcf0b110753e57be466e676f) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestFIFOCompactionPolicy.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/FIFOCompactionPolicy.java > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Assignee: Zheng Hu >Priority: Critical > Fix For: 3.0.0, 1.5.0, 2.2.0, 1.4.9, 2.1.2, 2.0.4 > > Attachments: 1.patch, HBASE-21504.v1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704689#comment-16704689
]
Hudson commented on HBASE-21504:
Results for branch master
[build #637 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/637/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/637//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/637//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/637//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704627#comment-16704627
]
Hudson commented on HBASE-21504:
Results for branch branch-2.1
[build #647 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/647/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/647//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/647//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/647//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704589#comment-16704589
]
Hudson commented on HBASE-21504:
Results for branch branch-2.0
[build #1125 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1125/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1125//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1125//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1125//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704572#comment-16704572
]
Hudson commented on HBASE-21504:
Results for branch branch-2
[build #1532 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1532/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1532//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1532//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1532//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704532#comment-16704532
]
Hudson commented on HBASE-21504:
Results for branch branch-1.4
[build #568 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/568/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/568//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/568//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/568//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704528#comment-16704528
]
Hudson commented on HBASE-21504:
Results for branch branch-1
[build #571 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/571/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/571//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/571//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/571//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704501#comment-16704501
]
Hudson commented on HBASE-21504:
Results for branch branch-1.2
[build #571 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/571/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/571//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/571//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/571//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- Something went wrong with this stage, [check relevant console
output|${BUILD_URL}/console].
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704482#comment-16704482
]
Hudson commented on HBASE-21504:
Results for branch branch-1.3
[build #560 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/560/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/560//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/560//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/560//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose
> maxTimeStamp is long max. This kind of hfile will never be archived.
> -
>
> Key: HBASE-21504
> URL: https://issues.apache.org/jira/browse/HBASE-21504
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.1.0
>Reporter: xuming
>Assignee: Zheng Hu
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4
>
> Attachments: 1.patch, HBASE-21504.v1.patch
>
>
> When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a
> region, once we do a compaction on the region, the compaction policy will
> select the latest hfile to do compaction.But beacuse the latest hfile is
> already TTL expired, compactor only write a "empty" hfile(whose entry counter
> is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is
> long max, so the "empty" hfile will never be TTL expired, more seriously we
> can not archive it by FIFOCompactionPolicy forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704179#comment-16704179 ] Hudson commented on HBASE-21504: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1187 (See [https://builds.apache.org/job/HBase-1.2-IT/1187/]) HBASE-21504 If enable FIFOCompactionPolicy, a compaction may write a (openinx: rev f49dbae937379888653e9417a314b0b9ead28d82) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestFIFOCompactionPolicy.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/FIFOCompactionPolicy.java > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Assignee: Zheng Hu >Priority: Critical > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4 > > Attachments: 1.patch, HBASE-21504.v1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704167#comment-16704167 ] Hudson commented on HBASE-21504: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #506 (See [https://builds.apache.org/job/HBase-1.3-IT/506/]) HBASE-21504 If enable FIFOCompactionPolicy, a compaction may write a (openinx: rev 57222ff0aa66047fc405c488f86a27b622beea64) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/FIFOCompactionPolicy.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestFIFOCompactionPolicy.java > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Assignee: Zheng Hu >Priority: Critical > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4 > > Attachments: 1.patch, HBASE-21504.v1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16704160#comment-16704160 ] Zheng Hu commented on HBASE-21504: -- Pushed to branch-2.x & branch-1.4 & branch-1.3 branch-1.2 & branch-1. Thanks [~allan163] for reviewing. > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Assignee: Zheng Hu >Priority: Critical > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4 > > Attachments: 1.patch, HBASE-21504.v1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[
https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16703226#comment-16703226
]
Hadoop QA commented on HBASE-21504:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
13s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
7s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 14s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}132m
56s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}172m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21504 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12949996/HBASE-21504.v1.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 1bc998800ba7 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct
31 10:55:11 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f1f2b5a038 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/15148/testReport/ |
| Max. process+thread count | 4648 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15148/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> If ena
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16703151#comment-16703151 ] Allan Yang commented on HBASE-21504: +1 for the patch > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Assignee: Zheng Hu >Priority: Critical > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 1.4.9, 2.1.2, 2.0.4 > > Attachments: 1.patch, HBASE-21504.v1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16698400#comment-16698400 ] Zheng Hu commented on HBASE-21504: -- Not in progress, I'll make this forward. > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Priority: Critical > Attachments: 1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695972#comment-16695972 ] Allan Yang commented on HBASE-21504: OK, for FIFOCompactionPolicy it is possible, a UT is needed. > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Priority: Critical > Attachments: 1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695963#comment-16695963 ] Zheng Hu commented on HBASE-21504: -- I think the problem is: the FIFOCompactionPolicy only choose those expired HFiles to compact. If a HFile with Long.MAX_VALUE timestamp, the FIFOCompactionPolicy will never choose it as a candidate ? > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Priority: Critical > Attachments: 1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695939#comment-16695939 ] Allan Yang commented on HBASE-21504: I think it is OK, if new KVs are writen to a new hfile, this empty HFile will compact with the new one and generate a normal HFile with kvs and the rignt time range. > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Priority: Critical > Attachments: 1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21504) If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose maxTimeStamp is long max. This kind of hfile will never be archived.
[ https://issues.apache.org/jira/browse/HBASE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694717#comment-16694717 ] Zheng Hu commented on HBASE-21504: -- Interesting, Could you please provide some UT for the bug fix ? I think it won't be too hard. Thanks > If enable FIFOCompactionPolicy, a compaction may write a "empty" hfile whose > maxTimeStamp is long max. This kind of hfile will never be archived. > - > > Key: HBASE-21504 > URL: https://issues.apache.org/jira/browse/HBASE-21504 > Project: HBase > Issue Type: Bug > Components: Compaction >Affects Versions: 2.1.0 >Reporter: xuming >Priority: Critical > Attachments: 1.patch > > > When i use FIFOCompactionPolicy, and if all hfiles(>1) are TTL expired in a > region, once we do a compaction on the region, the compaction policy will > select the latest hfile to do compaction.But beacuse the latest hfile is > already TTL expired, compactor only write a "empty" hfile(whose entry counter > is 0 and maxTimeStamp is Long.MAX_VALUE) finally. Because maxTimeStamp is > long max, so the "empty" hfile will never be TTL expired, more seriously we > can not archive it by FIFOCompactionPolicy forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
