[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598221#comment-16598221 ] Vishal Khandelwal commented on HBASE-20940: --- [~lhofhansl] I think changes done in [^PHOENIX-4839.patch] should mitigate the perf risk. preStoreScannerOpen method which makes the call to hasReference has been remove. We may still have this call during preCompact but IMO that should be fine. Also, we were coming to this situation mostly because of HBASE-21047 and once it is fixed I hope chances of hitting this would reduce. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940-branch-1-addendum.patch, > HBASE-20940.branch-1.3.v1.patch, HBASE-20940.branch-1.3.v2.patch, > HBASE-20940.branch-1.v1.patch, HBASE-20940.branch-1.v2.patch, > HBASE-20940.branch-1.v3.patch, HBASE-20940.branch-1.v5.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940-branch-1-addendum.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940-branch-1-addendum.patch, > HBASE-20940.branch-1.3.v1.patch, HBASE-20940.branch-1.3.v2.patch, > HBASE-20940.branch-1.v1.patch, HBASE-20940.branch-1.v2.patch, > HBASE-20940.branch-1.v3.patch, HBASE-20940.branch-1.v5.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594820#comment-16594820 ] Vishal Khandelwal commented on HBASE-20940: --- Hi [~apurtell], I have submitted the changes for branch-1 but it would not apply as it would conflict with my previously check-in code. I have run all small,medium,large test. It lgtm > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.branch-1.v5.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.v5.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.branch-1.v5.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: (was: HBASE-20940.branch-1.v5.patch) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.branch-1.v5.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594810#comment-16594810 ] Vishal Khandelwal commented on HBASE-20940: --- submitted the patch (HBASE-20940.branch-1.v5.patch) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.branch-1.v5.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.v5.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.branch-1.v5.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594520#comment-16594520 ] Vishal Khandelwal commented on HBASE-20940: --- [~apurtell] I have completed the patch and executing alll test. Somehow getting OOM while executing alltest. So trying to run small, large and medium separately. should be able to update patch by EOD. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 1.4.7, 2.0.3 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21105) TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
[
https://issues.apache.org/jira/browse/HBASE-21105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592391#comment-16592391
]
Vishal Khandelwal commented on HBASE-21105:
---
Thanks [~apurtell] and [~busbey]
I have fixed the dependency of TestEndToEndSplitTransaction on TestHBaseFSCK.
will combine this with HBASE-20940
> TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
> --
>
> Key: HBASE-21105
> URL: https://issues.apache.org/jira/browse/HBASE-21105
> Project: HBase
> Issue Type: Bug
> Components: hbck, test
>Affects Versions: 1.5.0, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Vishal Khandelwal
>Priority: Major
> Attachments: HBASE-21105.branch-1.v1.patch
>
>
> TestHBaseFsck in the mentioned branches has two tests that rely on
> TestEndToEndSplitTransaction for blocking in the same way TestTableResource
> used to before HBASE-21076.
> Both tests appear to specifically be testing that something happens after a
> split, so we'll need a solution that removes the cross-test dependency but
> still allows for "wait until this split has finished"
> example failure from branch-1
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testSplitDaughtersNotInMeta(TestHBaseFsck.java:1985)
> {code}
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testValidLingeringSplitParent(TestHBaseFsck.java:1934)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: (was: HBASE-20940.branch-1.v1.patch) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 2.0.2, 1.4.7 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592387#comment-16592387 ] Vishal Khandelwal commented on HBASE-20940: --- I think you want me to combine both patch together as one. I shall combine that on my monday morning. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 2.0.2, 1.4.7 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v1.patch, HBASE-20940.branch-1.v2.patch, > HBASE-20940.branch-1.v3.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592385#comment-16592385 ] Vishal Khandelwal commented on HBASE-20940: --- [~apurtell]: I have applied same fix as given "HBASE-21105" and it should be able to fix test blocker. Fix is only applicable for branch-1. Let me know if something else to be taken care > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 2.0.2, 1.4.7 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v1.patch, HBASE-20940.branch-1.v2.patch, > HBASE-20940.branch-1.v3.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.v1.patch Status: Patch Available (was: Reopened) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.3.3, 2.2.0, 2.1.1, 2.0.2, 1.4.7 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v1.patch, HBASE-20940.branch-1.v2.patch, > HBASE-20940.branch-1.v3.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21105) TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
[
https://issues.apache.org/jira/browse/HBASE-21105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-21105:
--
Attachment: HBASE-21105.branch-1.v1.patch
Status: Patch Available (was: Open)
{code}
{code:java}
[INFO] Running org.apache.hadoop.hbase.util.TestHBaseFsck
[WARNING] Tests run: 59, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
411.179 s - in org.apache.hadoop.hbase.util.TestHBaseFsck
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 59, Failures: 0, Errors: 0, Skipped: 1{code}
Full Build (hbase-server)
{code:java}
[WARNING] Tests run: 2349, Failures: 0, Errors: 0, Skipped: 64{code}
> TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
> --
>
> Key: HBASE-21105
> URL: https://issues.apache.org/jira/browse/HBASE-21105
> Project: HBase
> Issue Type: Bug
> Components: hbck, test
>Affects Versions: 1.5.0, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Vishal Khandelwal
>Priority: Major
> Attachments: HBASE-21105.branch-1.v1.patch
>
>
> TestHBaseFsck in the mentioned branches has two tests that rely on
> TestEndToEndSplitTransaction for blocking in the same way TestTableResource
> used to before HBASE-21076.
> Both tests appear to specifically be testing that something happens after a
> split, so we'll need a solution that removes the cross-test dependency but
> still allows for "wait until this split has finished"
> example failure from branch-1
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testSplitDaughtersNotInMeta(TestHBaseFsck.java:1985)
> {code}
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testValidLingeringSplitParent(TestHBaseFsck.java:1934)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-21105) TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
[
https://issues.apache.org/jira/browse/HBASE-21105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal reassigned HBASE-21105:
-
Assignee: Vishal Khandelwal
> TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
> --
>
> Key: HBASE-21105
> URL: https://issues.apache.org/jira/browse/HBASE-21105
> Project: HBase
> Issue Type: Bug
> Components: hbck, test
>Affects Versions: 1.5.0, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Assignee: Vishal Khandelwal
>Priority: Major
>
> TestHBaseFsck in the mentioned branches has two tests that rely on
> TestEndToEndSplitTransaction for blocking in the same way TestTableResource
> used to before HBASE-21076.
> Both tests appear to specifically be testing that something happens after a
> split, so we'll need a solution that removes the cross-test dependency but
> still allows for "wait until this split has finished"
> example failure from branch-1
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testSplitDaughtersNotInMeta(TestHBaseFsck.java:1985)
> {code}
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testValidLingeringSplitParent(TestHBaseFsck.java:1934)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21105) TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
[
https://issues.apache.org/jira/browse/HBASE-21105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591147#comment-16591147
]
Vishal Khandelwal commented on HBASE-21105:
---
Sure [~apurtell], will look into the failure provide patch. I looked it result
and somehow "TestHBaseFsck" did not run in results at all. I had attached
results ([^result_HBASE-20940.branch-1.v2.log)] also with " HBASE-20940" I
remember same thing happened with another test class as well.
> TestHBaseFsck failing in branch-1, branch-1.4, branch-1.3 with NPE
> --
>
> Key: HBASE-21105
> URL: https://issues.apache.org/jira/browse/HBASE-21105
> Project: HBase
> Issue Type: Bug
> Components: hbck, test
>Affects Versions: 1.5.0, 1.3.3, 1.4.7
>Reporter: Sean Busbey
>Priority: Major
>
> TestHBaseFsck in the mentioned branches has two tests that rely on
> TestEndToEndSplitTransaction for blocking in the same way TestTableResource
> used to before HBASE-21076.
> Both tests appear to specifically be testing that something happens after a
> split, so we'll need a solution that removes the cross-test dependency but
> still allows for "wait until this split has finished"
> example failure from branch-1
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testSplitDaughtersNotInMeta(TestHBaseFsck.java:1985)
> {code}
> {code}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testValidLingeringSplitParent(TestHBaseFsck.java:1934)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Status: Patch Available (was: Open) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[
https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583430#comment-16583430
]
Vishal Khandelwal commented on HBASE-20940:
---
Thanks [~apurtell] for looking into it and running the test. I am not sure why
my previous run did not show "org.apache.hadoop.hbase.regionserver.TestHRegion"
at all :( [^result_HBASE-20940.branch-1.v2.log] .
I have attached the latest patch fixing the TestHRegion#testMerge and following
are the results. Full run also seems fine to me now.
{code:java}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running
org.apache.hadoop.hbase.master.procedure.TestModifyNamespaceProcedure
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.131 s
- in org.apache.hadoop.hbase.master.procedure.TestModifyNamespaceProcedure
[INFO] Running org.apache.hadoop.hbase.regionserver.TestHRegion
[INFO] Tests run: 105, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 70.823
s - in org.apache.hadoop.hbase.regionserver.TestHRegion
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 111, Failures: 0, Errors: 0, Skipped: 0
{code}
> HStore.cansplit should not allow split to happen if it has references
> -
>
> Key: HBASE-20940
> URL: https://issues.apache.org/jira/browse/HBASE-20940
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20940.branch-1.3.v1.patch,
> HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch,
> HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch,
> HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch,
> HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log
>
>
> When split happens and immediately another split happens, it may result into
> a split of a region who still has references to its parent. More details
> about scenario can be found here HBASE-20933
> HStore.hasReferences should check from fs.storefile rather than in memory
> objects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: result_HBASE-20940.branch-1.v2.log > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch, result_HBASE-20940.branch-1.v2.log > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.v3.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.branch-1.v3.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582365#comment-16582365 ] Vishal Khandelwal commented on HBASE-20940: --- [~apurtell]: updated the patch for branch-1 as well. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.v2.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.branch-1.v2.patch, HBASE-20940.v1.patch, HBASE-20940.v2.patch, > HBASE-20940.v3.patch, HBASE-20940.v4.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582287#comment-16582287 ] Vishal Khandelwal commented on HBASE-21047: --- Thanks [~liuml07] [~apurtell]: PFA, patch for master branch > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.branch-1.v1.patch, > HBASE-21047.branch-1.v2.patch, HBASE-21047.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-21047: -- Attachment: HBASE-21047.v1.patch > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.branch-1.v1.patch, > HBASE-21047.branch-1.v2.patch, HBASE-21047.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-21047: -- Attachment: HBASE-21047.branch-1.v2.patch > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.branch-1.v1.patch, > HBASE-21047.branch-1.v2.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[
https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581937#comment-16581937
]
Vishal Khandelwal commented on HBASE-21047:
---
Thanks [~apurtell] and [~liuml07]
[~apurtell]
> Does this impact branch-2 and master? Or only branch-1? My guess is all. We
>will need patches for master at least to commit down the line.
Nope it should impact master as well, I would get the patch for master as well.
> From an interaction we've had I know this is Phoenix related, needed for
> local indexes to work properly. Is there a Phoenix JIRA for that? If not can
> you file it and link it here?
This fix only should resolve the phoenix issue and no additional changes would
be required in phoenix. But I have opened "PHOENIX-4852" to make this change is
picked up before using localindexes
[~liuml07]
> I don't see direct call of the constructor other than
> {{StoreFile::getStoreFileScanner()}} method. But I like the idea of increase
> / decrease safely in the same class. +1 (non-binding)
Origin of the issue is via phoenix (PHOENIX-4852) but in theory any
co-processor (/class) extending StoreFileScanner can hit this issue. Within
HBase there are no direct constructor calls.
> Nit: in test {{HColumnDescriptor hcd = mock(HColumnDescriptor.class);}} seems
> not useful. We can delete it.
will make that change in patch.
> Object creation of StoreFileScanner thru constructor and close may leave
> refCount to -1
> ---
>
> Key: HBASE-21047
> URL: https://issues.apache.org/jira/browse/HBASE-21047
> Project: HBase
> Issue Type: Bug
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-21047.branch-1.v1.patch
>
>
> During object creation "*StoreFileScanner*", it does not increase the
> refCount whereas while close it decrements the reader refCount. This will
> cause refCount to -1 and isReadReference method was returning true
> (refCount.get() != 0 This is causing store file not to be deleted. This may
> also cause issue in situation when some thread is holding a scanner but it
> may actually be closed due to above bug. Impact of this would be really high.
> Attatching patch for the fix which makes sure if reference is held either
> thru getScanner method or constructor, ref is always updated. Patch also
> contains a test which validates the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21063) IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner which would store file reference count to -1
[ https://issues.apache.org/jira/browse/HBASE-21063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581931#comment-16581931 ] Vishal Khandelwal edited comment on HBASE-21063 at 8/16/18 4:22 AM: Openen by mistake in hbase, it is phoenix JIRA was (Author: vishk): Openen by mistake in hbase. > IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner > which would store file reference count to -1 > --- > > Key: HBASE-21063 > URL: https://issues.apache.org/jira/browse/HBASE-21063 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Priority: Major > Labels: LocalIndex > > Actual fix of this bug is in the [link > HBASE-21047|https://issues.apache.org/jira/browse/HBASE-21047]. > Object to LocalIndexStoreFileScanner and StoreFileScanner in class > IndexHalfStoreFileReaderGenerator would leave the fileReference in > inconsistent state. Opening this bug here to make sure above HBASE patch > needs to be picked up for running any instance of phoenix local indexes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21063) IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner which would store file reference count to -1
[ https://issues.apache.org/jira/browse/HBASE-21063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal resolved HBASE-21063. --- Resolution: Duplicate > IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner > which would store file reference count to -1 > --- > > Key: HBASE-21063 > URL: https://issues.apache.org/jira/browse/HBASE-21063 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Priority: Major > Labels: LocalIndex > > Actual fix of this bug is in the [link > HBASE-21047|https://issues.apache.org/jira/browse/HBASE-21047]. > Object to LocalIndexStoreFileScanner and StoreFileScanner in class > IndexHalfStoreFileReaderGenerator would leave the fileReference in > inconsistent state. Opening this bug here to make sure above HBASE patch > needs to be picked up for running any instance of phoenix local indexes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21063) IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner which would store file reference count to -1
[ https://issues.apache.org/jira/browse/HBASE-21063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581931#comment-16581931 ] Vishal Khandelwal commented on HBASE-21063: --- Openen by mistake in hbase. > IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner > which would store file reference count to -1 > --- > > Key: HBASE-21063 > URL: https://issues.apache.org/jira/browse/HBASE-21063 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Priority: Major > Labels: LocalIndex > > Actual fix of this bug is in the [link > HBASE-21047|https://issues.apache.org/jira/browse/HBASE-21047]. > Object to LocalIndexStoreFileScanner and StoreFileScanner in class > IndexHalfStoreFileReaderGenerator would leave the fileReference in > inconsistent state. Opening this bug here to make sure above HBASE patch > needs to be picked up for running any instance of phoenix local indexes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21063) IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner which would store file reference count to -1
Vishal Khandelwal created HBASE-21063: - Summary: IndexHalfStoreFileReaderGenerator.getLocalIndexScanners creates an scanner which would store file reference count to -1 Key: HBASE-21063 URL: https://issues.apache.org/jira/browse/HBASE-21063 Project: HBase Issue Type: Bug Reporter: Vishal Khandelwal Actual fix of this bug is in the [link HBASE-21047|https://issues.apache.org/jira/browse/HBASE-21047]. Object to LocalIndexStoreFileScanner and StoreFileScanner in class IndexHalfStoreFileReaderGenerator would leave the fileReference in inconsistent state. Opening this bug here to make sure above HBASE patch needs to be picked up for running any instance of phoenix local indexes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20933) multiple splits may result into forever uncleaned split region
[ https://issues.apache.org/jira/browse/HBASE-20933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16579317#comment-16579317 ] Vishal Khandelwal commented on HBASE-20933: --- I tried to solve this issue via fix in catalogJanitor but this does not seem to be correct way of solving the issue as it may lead into the references which are lingering. Ideally problem should not arrive after fix of "HBASE-20940 " but incase it arises it would never be cleaned up. Since this region is offline and not deployed, I do not think we can do it thru "CompactedHFilesDischarger" as non-deployed region can be picked by RSservice. That leaves both of the suggest solutions to be not correct solutions. IMO, ideally we should fix thru some masterservice which can compact/remove reference from offline parent region. Seeking suggestions for the same. > multiple splits may result into forever uncleaned split region > -- > > Key: HBASE-20933 > URL: https://issues.apache.org/jira/browse/HBASE-20933 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: HBASE-20933.patch, Test123.java > > > Incase of multiple subsequent split and with an open handle on old reference > file, it may result into split region which can never be cleaned > So Here are two issues. > # Region is getting split even when it has reference to its parent > # Region is going offline/in archive mode even when there are reference > pending in store > *Repro Steps* > # Region split (P) > # Before major compaction starts after split, open a handle on store file on > new region (DA & DB) > # Let compaction completes on DA, (Here compaction will not clear reference > store files as it is opened) > # Split new region (DA) again ( shouldSplit will return true as before > compaction even does the cleanup, it removes the compacted files and > reference in-memory list) > # Now CatalogJanitor will not remove this region as it has store references, > majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only > looks at only online regions > # After above steps region-DA which is offline will always be in split > regions and never getting cleaned up. > We found that catalog janitor is also not able to clean regions which are > offline(split parent) because it has reference of the daughter of it's parent > which is not getting cleaned up. This is causing lot of store files not > getting cleaned causing more space in local index store and lot of split > lingering regions. > Unit test repro the scenario has been attached. > Fix can be in CompactedHFilesDischarger or catalogJanitor to handle such > cases. Even if such region exists which are offline and are split region. > They should be able to clean t hem selves -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20933) multiple splits may result into forever uncleaned split region
[ https://issues.apache.org/jira/browse/HBASE-20933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20933: -- Attachment: HBASE-20933.patch > multiple splits may result into forever uncleaned split region > -- > > Key: HBASE-20933 > URL: https://issues.apache.org/jira/browse/HBASE-20933 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: HBASE-20933.patch, Test123.java > > > Incase of multiple subsequent split and with an open handle on old reference > file, it may result into split region which can never be cleaned > So Here are two issues. > # Region is getting split even when it has reference to its parent > # Region is going offline/in archive mode even when there are reference > pending in store > *Repro Steps* > # Region split (P) > # Before major compaction starts after split, open a handle on store file on > new region (DA & DB) > # Let compaction completes on DA, (Here compaction will not clear reference > store files as it is opened) > # Split new region (DA) again ( shouldSplit will return true as before > compaction even does the cleanup, it removes the compacted files and > reference in-memory list) > # Now CatalogJanitor will not remove this region as it has store references, > majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only > looks at only online regions > # After above steps region-DA which is offline will always be in split > regions and never getting cleaned up. > We found that catalog janitor is also not able to clean regions which are > offline(split parent) because it has reference of the daughter of it's parent > which is not getting cleaned up. This is causing lot of store files not > getting cleaned causing more space in local index store and lot of split > lingering regions. > Unit test repro the scenario has been attached. > Fix can be in CompactedHFilesDischarger or catalogJanitor to handle such > cases. Even if such region exists which are offline and are split region. > They should be able to clean t hem selves -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-21047: -- Attachment: (was: HBASE-21047.v1.patch) > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.branch-1.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-21047: -- Attachment: HBASE-21047.branch-1.v1.patch > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.branch-1.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16579301#comment-16579301 ] Vishal Khandelwal commented on HBASE-21047: --- Submitted the changes for branch-1.0 and after reviewing can submit the changes for master. For master code layout is little different and would need to update the changes accordingly. All test expect below which was failing before the change testAllowedClient(org.apache.hadoop.hbase.http.TestSpnegoHttpServer [~apurtell] > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-21047: -- Fix Version/s: 1.5.0 Status: Patch Available (was: Open) > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21047.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
[ https://issues.apache.org/jira/browse/HBASE-21047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-21047: -- Attachment: HBASE-21047.v1.patch > Object creation of StoreFileScanner thru constructor and close may leave > refCount to -1 > --- > > Key: HBASE-21047 > URL: https://issues.apache.org/jira/browse/HBASE-21047 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: HBASE-21047.v1.patch > > > During object creation "*StoreFileScanner*", it does not increase the > refCount whereas while close it decrements the reader refCount. This will > cause refCount to -1 and isReadReference method was returning true > (refCount.get() != 0 This is causing store file not to be deleted. This may > also cause issue in situation when some thread is holding a scanner but it > may actually be closed due to above bug. Impact of this would be really high. > Attatching patch for the fix which makes sure if reference is held either > thru getScanner method or constructor, ref is always updated. Patch also > contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21047) Object creation of StoreFileScanner thru constructor and close may leave refCount to -1
Vishal Khandelwal created HBASE-21047: - Summary: Object creation of StoreFileScanner thru constructor and close may leave refCount to -1 Key: HBASE-21047 URL: https://issues.apache.org/jira/browse/HBASE-21047 Project: HBase Issue Type: Bug Reporter: Vishal Khandelwal Assignee: Vishal Khandelwal During object creation "*StoreFileScanner*", it does not increase the refCount whereas while close it decrements the reader refCount. This will cause refCount to -1 and isReadReference method was returning true (refCount.get() != 0 This is causing store file not to be deleted. This may also cause issue in situation when some thread is holding a scanner but it may actually be closed due to above bug. Impact of this would be really high. Attatching patch for the fix which makes sure if reference is held either thru getScanner method or constructor, ref is always updated. Patch also contains a test which validates the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577898#comment-16577898 ] Vishal Khandelwal commented on HBASE-20940: --- I did the complete run and found following failures irrespective of patch. Rest other passed. [ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 1.539 s <<< FAILURE! - in org.apache.hadoop.hbase.regionserver.TestDataBlockEncodingTool [ERROR] testHFileAllCellsWithTags(org.apache.hadoop.hbase.regionserver.TestDataBlockEncodingTool) Time elapsed: 0.887 s <<< ERROR! java.lang.IllegalArgumentException > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577845#comment-16577845 ] Vishal Khandelwal commented on HBASE-20940: --- For build following did not fail as it is skip test list. TestNamespaceAuditor > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.v4.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch, > HBASE-20940.v4.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577832#comment-16577832 ] Vishal Khandelwal commented on HBASE-20940: --- Sorry [~apurtell] I reran the test TestNamespaceAuditor.testRegionMerge on branch-2 and it failed this time may because of CompactDistacher frequency cleanup. not sure it did not fail earlier for me earlier and even reports did not showed so. I have fix the test now, hopefully this time it should pass. I am attaching the master branch patch. There additional changes(test) in branch.1 & branch-1.3, I will upload other branch fixes as well after master > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571360#comment-16571360 ] Vishal Khandelwal commented on HBASE-20940: --- For check-style: I am getting import order check failure but order seems to be correct. ./hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestEndToEndSplitTransaction.java:68:import org.junit.AfterClass;: Wrong order for 'org.junit.AfterClass' import. [ImportOrder] For test failure, I reran the test and it worked fine. I have resubmitted the patch For FindBugs, I have fixed and submitted the patch again.(v3) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.v3.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch, HBASE-20940.v3.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Fix Version/s: (was: 1.3.2) 3.0.0 Status: Patch Available (was: Open) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.v2.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch, HBASE-20940.v2.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1653#comment-1653 ] Vishal Khandelwal commented on HBASE-20940: --- [~yuzhih...@gmail.com] updated the patch for branch-1.3, branch-1 and master. master patch is compatible with branch2.0 and other were not. I have also fixed the test failures in latest patches. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.v1.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.branch-1.v1.patch, > HBASE-20940.v1.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Description: When split happens and immediately another split happens, it may result into a split of a region who still has references to its parent. More details about scenario can be found here HBASE-20933 HStore.hasReferences should check from fs.storefile rather than in memory objects. was: When split happens ans immediately another split happens, it may result into a split of a region who still has references to its parent. More details about scenario can be found here HBASE-20933 HStore.hasReferences should check from fs.storefile rather than in memory objects. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.v1.patch > > > When split happens and immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.branch-1.3.v2.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, > HBASE-20940.branch-1.3.v2.patch, HBASE-20940.v1.patch > > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: (was: HBASE-20940.v1.patch) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, HBASE-20940.v1.patch > > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.v1.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, HBASE-20940.v1.patch > > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Attachment: HBASE-20940.v1.patch > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch, HBASE-20940.v1.patch > > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565183#comment-16565183 ] Vishal Khandelwal commented on HBASE-20940: --- [~yuzhih...@gmail.com] i am working on master branch. will update the patch as soon as it is ready. > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch > > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Fix Version/s: 1.3.2 Attachment: HBASE-20940.branch-1.3.v1.patch Status: Patch Available (was: Open) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Fix For: 1.3.2 > > Attachments: HBASE-20940.branch-1.3.v1.patch > > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559268#comment-16559268
]
Vishal Khandelwal commented on HBASE-20930:
---
I have uploaded the new patch [~elserj]
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20930.branch-1.3.patch,
> HBASE-20930.branch-1.3.v2.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20930:
--
Attachment: HBASE-20930.branch-1.3.v2.patch
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20930.branch-1.3.patch,
> HBASE-20930.branch-1.3.v2.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558541#comment-16558541
]
Vishal Khandelwal commented on HBASE-20930:
---
Thanks [~elserj] for review. I am fine with anything but I can do these changes
tomorrow when @ work.
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20930.branch-1.3.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16556884#comment-16556884 ] Vishal Khandelwal commented on HBASE-20935: --- Thanks [~yuzhih...@gmail.com] for review. I have updated the patch. > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Fix For: 1.3.3 > > Attachments: HBASE-20935.branch-1.3.patch, > HBASE-20935.branch-1.3.v2.patch, HBASE-20935.patch, HBASE-20935.v2.patch > > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20935: -- Attachment: HBASE-20935.v2.patch HBASE-20935.branch-1.3.v2.patch > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Fix For: 1.3.3 > > Attachments: HBASE-20935.branch-1.3.patch, > HBASE-20935.branch-1.3.v2.patch, HBASE-20935.patch, HBASE-20935.v2.patch > > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16556878#comment-16556878
]
Vishal Khandelwal commented on HBASE-20930:
---
Thanks [~elserj]. Yeah by mistake I attached patch of different JIRA
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20930.branch-1.3.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20930:
--
Attachment: (was: HBASE-20935.branch-1.3.patch)
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20930.branch-1.3.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20930:
--
Attachment: HBASE-20930.branch-1.3.patch
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20930.branch-1.3.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20940) HStore.cansplit should not be allow split to happen if it has references
Vishal Khandelwal created HBASE-20940: - Summary: HStore.cansplit should not be allow split to happen if it has references Key: HBASE-20940 URL: https://issues.apache.org/jira/browse/HBASE-20940 Project: HBase Issue Type: Bug Affects Versions: 1.3.2 Reporter: Vishal Khandelwal Assignee: Vishal Khandelwal When split happens ans immediately another split happens, it may result into a split of a region who still has references to its parent. More details about scenario can be found here HBASE-20933 HStore.hasReferences should check from fs.storefile rather than in memory objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20930:
--
Fix Version/s: 1.3.3
Affects Version/s: 1.3.3
Attachment: HBASE-20935.branch-1.3.patch
Status: Patch Available (was: Open)
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 1.3.3
>
> Attachments: HBASE-20935.branch-1.3.patch
>
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20940) HStore.cansplit should not allow split to happen if it has references
[ https://issues.apache.org/jira/browse/HBASE-20940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20940: -- Summary: HStore.cansplit should not allow split to happen if it has references (was: HStore.cansplit should not be allow split to happen if it has references) > HStore.cansplit should not allow split to happen if it has references > - > > Key: HBASE-20940 > URL: https://issues.apache.org/jira/browse/HBASE-20940 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > > When split happens ans immediately another split happens, it may result into > a split of a region who still has references to its parent. More details > about scenario can be found here HBASE-20933 > HStore.hasReferences should check from fs.storefile rather than in memory > objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20933) multiple splits may result into forever uncleaned split region
[ https://issues.apache.org/jira/browse/HBASE-20933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20933: -- Description: Incase of multiple subsequent split and with an open handle on old reference file, it may result into split region which can never be cleaned So Here are two issues. # Region is getting split even when it has reference to its parent # Region is going offline/in archive mode even when there are reference pending in store *Repro Steps* # Region split (P) # Before major compaction starts after split, open a handle on store file on new region (DA & DB) # Let compaction completes on DA, (Here compaction will not clear reference store files as it is opened) # Split new region (DA) again ( shouldSplit will return true as before compaction even does the cleanup, it removes the compacted files and reference in-memory list) # Now CatalogJanitor will not remove this region as it has store references, majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only looks at only online regions # After above steps region-DA which is offline will always be in split regions and never getting cleaned up. We found that catalog janitor is also not able to clean regions which are offline(split parent) because it has reference of the daughter of it's parent which is not getting cleaned up. This is causing lot of store files not getting cleaned causing more space in local index store and lot of split lingering regions. Unit test repro the scenario has been attached. Fix can be in CompactedHFilesDischarger or catalogJanitor to handle such cases. Even if such region exists which are offline and are split region. They should be able to clean t hem selves was: Incase of multiple subsequent split and with an open handle on old reference file, it may result into split region which can never be cleaned So Here are two issues. # Region is getting split even when it has reference to its parent # Region is going offline/in archive mode even when there are reference pending in store *Repro Steps* # Region split (P) # Before major compaction starts after split, open a handle on store file on new region (DA & DB) # Let compaction completes on DA, (Here compaction will not clear reference store files as it is opened) # Split new region (DA) again ( shouldSplit will return true as before compaction even does the cleanup, it removes the compacted files and reference in-memory list) # Now CatalogJanitor will not remove this region as it has store references, majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only looks at only online regions # After above steps region-DA which is offline will always be in split regions and never getting cleaned up. We found that catalog janitor is also not able to clean regions which are offline(split parent) because it has reference of the daughter of it's parent which is not getting cleaned up. This is causing lot of store files not getting cleaned causing more space in local index store and lot of split lingering regions. Unit test repro the scenario has been attached. Fix can be in CompactedHFilesDischarger or catalogJanitor to handle sch case > multiple splits may result into forever uncleaned split region > -- > > Key: HBASE-20933 > URL: https://issues.apache.org/jira/browse/HBASE-20933 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: Test123.java > > > Incase of multiple subsequent split and with an open handle on old reference > file, it may result into split region which can never be cleaned > So Here are two issues. > # Region is getting split even when it has reference to its parent > # Region is going offline/in archive mode even when there are reference > pending in store > *Repro Steps* > # Region split (P) > # Before major compaction starts after split, open a handle on store file on > new region (DA & DB) > # Let compaction completes on DA, (Here compaction will not clear reference > store files as it is opened) > # Split new region (DA) again ( shouldSplit will return true as before > compaction even does the cleanup, it removes the compacted files and > reference in-memory list) > # Now CatalogJanitor will not remove this region as it has store references, > majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only > looks at only online regions > # After above steps region-DA which is offline will always be in split > regions and never getting cleaned up. > We found that catalog janitor is also not able to clean regions which are > offline(split parent) because it has reference of the daughter of it's
[jira] [Updated] (HBASE-20933) multiple splits may result into forever uncleaned split region
[ https://issues.apache.org/jira/browse/HBASE-20933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20933: -- Description: Incase of multiple subsequent split and with an open handle on old reference file, it may result into split region which can never be cleaned So Here are two issues. # Region is getting split even when it has reference to its parent # Region is going offline/in archive mode even when there are reference pending in store *Repro Steps* # Region split (P) # Before major compaction starts after split, open a handle on store file on new region (DA & DB) # Let compaction completes on DA, (Here compaction will not clear reference store files as it is opened) # Split new region (DA) again ( shouldSplit will return true as before compaction even does the cleanup, it removes the compacted files and reference in-memory list) # Now CatalogJanitor will not remove this region as it has store references, majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only looks at only online regions # After above steps region-DA which is offline will always be in split regions and never getting cleaned up. We found that catalog janitor is also not able to clean regions which are offline(split parent) because it has reference of the daughter of it's parent which is not getting cleaned up. This is causing lot of store files not getting cleaned causing more space in local index store and lot of split lingering regions. Unit test repro the scenario has been attached. Fix can be in CompactedHFilesDischarger or catalogJanitor to handle sch case was: Incase of multiple subsequent split and with an open handle on old reference file, it may result into split region which can never be cleaned So Here are two issues. # Region is getting split even when it has reference to its parent # Region is going offline/in archive mode even when there are reference pending in store *Repro Steps* # Region split (P) # Before major compaction starts after split, open a handle on store file on new region (DA & DB) # Let compaction completes on DA, (Here compaction will not clear reference store files as it is opened) # Split new region (DA) again ( shouldSplit will return true as before compaction even does the cleanup, it removes the compacted files and reference in-memory list) # Now CatalogJanitor will not remove this region as it has store references, majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only looks at only online regions # After above steps region-DA which is offline will always be in split regions and never getting cleaned up. We found that catalog janitor is also not able to clean regions which are offline(split parent) because it has reference of the daughter of it's parent which is not getting cleaned up. This is causing lot of store files not getting cleaned causing more space in local index store and lot of split lingering regions. Unit test repro the scenario has been attached. Fix can be in CompactedHFilesDischarger to look into offline region or stop split in such cases. > multiple splits may result into forever uncleaned split region > -- > > Key: HBASE-20933 > URL: https://issues.apache.org/jira/browse/HBASE-20933 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: Test123.java > > > Incase of multiple subsequent split and with an open handle on old reference > file, it may result into split region which can never be cleaned > So Here are two issues. > # Region is getting split even when it has reference to its parent > # Region is going offline/in archive mode even when there are reference > pending in store > *Repro Steps* > # Region split (P) > # Before major compaction starts after split, open a handle on store file on > new region (DA & DB) > # Let compaction completes on DA, (Here compaction will not clear reference > store files as it is opened) > # Split new region (DA) again ( shouldSplit will return true as before > compaction even does the cleanup, it removes the compacted files and > reference in-memory list) > # Now CatalogJanitor will not remove this region as it has store references, > majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only > looks at only online regions > # After above steps region-DA which is offline will always be in split > regions and never getting cleaned up. > We found that catalog janitor is also not able to clean regions which are > offline(split parent) because it has reference of the daughter of it's parent > which is not getting cleaned up. This is causing lot of store files not > getting
[jira] [Updated] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20935: -- Attachment: HBASE-20935.patch HBASE-20935.branch-1.3.patch > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Fix For: 1.3.3 > > Attachments: HBASE-20935.branch-1.3.patch, HBASE-20935.patch > > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20935: -- Attachment: (was: HBASE-20935.patch) > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Fix For: 1.3.3 > > Attachments: HBASE-20935.branch-1.3.patch, HBASE-20935.patch > > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20935: -- Fix Version/s: 1.3.3 Status: Patch Available (was: Open) > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Fix For: 1.3.3 > > Attachments: HBASE-20935.patch > > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20935: -- Attachment: HBASE-20935.patch > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Attachments: HBASE-20935.patch > > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555126#comment-16555126 ] Vishal Khandelwal commented on HBASE-20935: --- Will submit the patch for log line change > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20933) multiple splits may result into forever uncleaned split region
[ https://issues.apache.org/jira/browse/HBASE-20933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555124#comment-16555124 ] Vishal Khandelwal commented on HBASE-20933: --- Will be working on patch for this issue > multiple splits may result into forever uncleaned split region > -- > > Key: HBASE-20933 > URL: https://issues.apache.org/jira/browse/HBASE-20933 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: Test123.java > > > Incase of multiple subsequent split and with an open handle on old reference > file, it may result into split region which can never be cleaned > So Here are two issues. > # Region is getting split even when it has reference to its parent > # Region is going offline/in archive mode even when there are reference > pending in store > *Repro Steps* > # Region split (P) > # Before major compaction starts after split, open a handle on store file on > new region (DA & DB) > # Let compaction completes on DA, (Here compaction will not clear reference > store files as it is opened) > # Split new region (DA) again ( shouldSplit will return true as before > compaction even does the cleanup, it removes the compacted files and > reference in-memory list) > # Now CatalogJanitor will not remove this region as it has store references, > majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only > looks at only online regions > # After above steps region-DA which is offline will always be in split > regions and never getting cleaned up. > We found that catalog janitor is also not able to clean regions which are > offline(split parent) because it has reference of the daughter of it's parent > which is not getting cleaned up. This is causing lot of store files not > getting cleaned causing more space in local index store and lot of split > lingering regions. > Unit test repro the scenario has been attached. > Fix can be in CompactedHFilesDischarger to look into offline region or stop > split in such cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
[ https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20935: -- Description: if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) If above check fails then there will be some files which are compacted but not getting cleaned up. It is good to log which helps in debugging the issue. This would let us know why is getting cleaned. either with reference pending or compatedaway is not set. This will help debug issues like : # HBASE-20933 was: if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) If above check fails then there will be some files which are compacted but not getting cleaned up. It is good to log which helps in debugging the issue. This would let us know why is getting cleaned. either with reference pending or compatedaway is not set. > HStore.removeCompactedfiles should log incase it unable to delete a file > > > Key: HBASE-20935 > URL: https://issues.apache.org/jira/browse/HBASE-20935 > Project: HBase > Issue Type: Improvement >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > > if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) > If above check fails then there will be some files which are compacted but > not getting cleaned up. It is good to log which helps in debugging the issue. > This would let us know why is getting cleaned. either with reference pending > or compatedaway is not set. > This will help debug issues like : > # HBASE-20933 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20935) HStore.removeCompactedfiles should log incase it unable to delete a file
Vishal Khandelwal created HBASE-20935: - Summary: HStore.removeCompactedfiles should log incase it unable to delete a file Key: HBASE-20935 URL: https://issues.apache.org/jira/browse/HBASE-20935 Project: HBase Issue Type: Improvement Reporter: Vishal Khandelwal Assignee: Vishal Khandelwal if (r != null && r.isCompactedAway() && !r.isReferencedInReads()) If above check fails then there will be some files which are compacted but not getting cleaned up. It is good to log which helps in debugging the issue. This would let us know why is getting cleaned. either with reference pending or compatedaway is not set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20933) multiple splits may result into forever uncleaned split region
[ https://issues.apache.org/jira/browse/HBASE-20933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-20933: -- Attachment: Test123.java > multiple splits may result into forever uncleaned split region > -- > > Key: HBASE-20933 > URL: https://issues.apache.org/jira/browse/HBASE-20933 > Project: HBase > Issue Type: Bug >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Major > Attachments: Test123.java > > > Incase of multiple subsequent split and with an open handle on old reference > file, it may result into split region which can never be cleaned > So Here are two issues. > # Region is getting split even when it has reference to its parent > # Region is going offline/in archive mode even when there are reference > pending in store > *Repro Steps* > # Region split (P) > # Before major compaction starts after split, open a handle on store file on > new region (DA & DB) > # Let compaction completes on DA, (Here compaction will not clear reference > store files as it is opened) > # Split new region (DA) again ( shouldSplit will return true as before > compaction even does the cleanup, it removes the compacted files and > reference in-memory list) > # Now CatalogJanitor will not remove this region as it has store references, > majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only > looks at only online regions > # After above steps region-DA which is offline will always be in split > regions and never getting cleaned up. > We found that catalog janitor is also not able to clean regions which are > offline(split parent) because it has reference of the daughter of it's parent > which is not getting cleaned up. This is causing lot of store files not > getting cleaned causing more space in local index store and lot of split > lingering regions. > Unit test repro the scenario has been attached. > Fix can be in CompactedHFilesDischarger to look into offline region or stop > split in such cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20933) multiple splits may result into forever uncleaned split region
Vishal Khandelwal created HBASE-20933: - Summary: multiple splits may result into forever uncleaned split region Key: HBASE-20933 URL: https://issues.apache.org/jira/browse/HBASE-20933 Project: HBase Issue Type: Bug Reporter: Vishal Khandelwal Assignee: Vishal Khandelwal Incase of multiple subsequent split and with an open handle on old reference file, it may result into split region which can never be cleaned So Here are two issues. # Region is getting split even when it has reference to its parent # Region is going offline/in archive mode even when there are reference pending in store *Repro Steps* # Region split (P) # Before major compaction starts after split, open a handle on store file on new region (DA & DB) # Let compaction completes on DA, (Here compaction will not clear reference store files as it is opened) # Split new region (DA) again ( shouldSplit will return true as before compaction even does the cleanup, it removes the compacted files and reference in-memory list) # Now CatalogJanitor will not remove this region as it has store references, majorCompaction/CompactedHFilesDischarger will not do the cleanup as it only looks at only online regions # After above steps region-DA which is offline will always be in split regions and never getting cleaned up. We found that catalog janitor is also not able to clean regions which are offline(split parent) because it has reference of the daughter of it's parent which is not getting cleaned up. This is causing lot of store files not getting cleaned causing more space in local index store and lot of split lingering regions. Unit test repro the scenario has been attached. Fix can be in CompactedHFilesDischarger to look into offline region or stop split in such cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20929) IncreasingToUpperBoundRegionSplitPolicy -> shouldSplit -> Log.debug should be enclosed inside LOG.isdebugEnabled()
[
https://issues.apache.org/jira/browse/HBASE-20929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554557#comment-16554557
]
Vishal Khandelwal commented on HBASE-20929:
---
[~elserj] sure will provide the patch for this.
> IncreasingToUpperBoundRegionSplitPolicy -> shouldSplit -> Log.debug should be
> enclosed inside LOG.isdebugEnabled()
> --
>
> Key: HBASE-20929
> URL: https://issues.apache.org/jira/browse/HBASE-20929
> Project: HBase
> Issue Type: Improvement
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
>
> Class IncreasingToUpperBoundRegionSplitPolicy.
>
> if (size > sizeToCheck) {
> LOG.debug("ShouldSplit because " + store.getColumnFamilyName() + " size=" +
> size
> + ", sizeToCheck=" + sizeToCheck + ", regionsWithCommonTable="
> + tableRegionsCount);
> foundABigStore = true;
> }
>
> LOG.debug("Failed getOnlineRegions " + tablename, e);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
[
https://issues.apache.org/jira/browse/HBASE-20930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554555#comment-16554555
]
Vishal Khandelwal commented on HBASE-20930:
---
[~elserj]: Yep I will provide the patch for this change.
> MetaScanner.metaScan should use passed variable for meta table name rather
> than TableName.META_TABLE_NAME
> -
>
> Key: HBASE-20930
> URL: https://issues.apache.org/jira/browse/HBASE-20930
> Project: HBase
> Issue Type: Improvement
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
>
> MetaScanner.metaScan
> try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
> null)) {
> should be changed to
> metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
> metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20930) MetaScanner.metaScan should use passed variable for meta table name rather than TableName.META_TABLE_NAME
Vishal Khandelwal created HBASE-20930:
-
Summary: MetaScanner.metaScan should use passed variable for meta
table name rather than TableName.META_TABLE_NAME
Key: HBASE-20930
URL: https://issues.apache.org/jira/browse/HBASE-20930
Project: HBase
Issue Type: Bug
Reporter: Vishal Khandelwal
Assignee: Vishal Khandelwal
MetaScanner.metaScan
try (Table metaTable = new HTable(TableName.META_TABLE_NAME, connection,
null)) {
should be changed to
metaScan(connection, visitor, userTableName, null, Integer.MAX_VALUE,
metaTableName)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20929) IncreasingToUpperBoundRegionSplitPolicy -> shouldSplit -> Log.debug should be enclosed inside LOG.isdebugEnabled()
Vishal Khandelwal created HBASE-20929:
-
Summary: IncreasingToUpperBoundRegionSplitPolicy -> shouldSplit ->
Log.debug should be enclosed inside LOG.isdebugEnabled()
Key: HBASE-20929
URL: https://issues.apache.org/jira/browse/HBASE-20929
Project: HBase
Issue Type: Bug
Reporter: Vishal Khandelwal
Assignee: Vishal Khandelwal
Class IncreasingToUpperBoundRegionSplitPolicy.
if (size > sizeToCheck) {
LOG.debug("ShouldSplit because " + store.getColumnFamilyName() + " size=" +
size
+ ", sizeToCheck=" + sizeToCheck + ", regionsWithCommonTable="
+ tableRegionsCount);
foundABigStore = true;
}
LOG.debug("Failed getOnlineRegions " + tablename, e);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20302) CatalogJanitor should log the reason why it is disable
[
https://issues.apache.org/jira/browse/HBASE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20302:
--
Status: Patch Available (was: Open)
Fix was already there in branch-2 and above. porting it to branch-1 with minor
changes.
> CatalogJanitor should log the reason why it is disable
> --
>
> Key: HBASE-20302
> URL: https://issues.apache.org/jira/browse/HBASE-20302
> Project: HBase
> Issue Type: Bug
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Major
> Attachments: HBASE-20302.branch-1.v1.patch
>
>
> when catalogJanitor is disabled it has various condition for which it can be
> true to disable CatalogJanitor and sends this message "CatalogJanitor
> disabled! Not running scan." Since this is an async thread, it is difficult
> to identify what is the exact reason for it disable. We could log all
> conditions alongwith LOG.warn("CatalogJanitor disabled! Not running scan.")
> for better debugging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20302) CatalogJanitor should log the reason why it is disabled
[
https://issues.apache.org/jira/browse/HBASE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20302:
--
Summary: CatalogJanitor should log the reason why it is disabled (was:
CatalogJanitor should log the reason why it is disable)
> CatalogJanitor should log the reason why it is disabled
> ---
>
> Key: HBASE-20302
> URL: https://issues.apache.org/jira/browse/HBASE-20302
> Project: HBase
> Issue Type: Bug
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Major
> Attachments: HBASE-20302.branch-1.v1.patch
>
>
> when catalogJanitor is disabled it has various condition for which it can be
> true to disable CatalogJanitor and sends this message "CatalogJanitor
> disabled! Not running scan." Since this is an async thread, it is difficult
> to identify what is the exact reason for it disable. We could log all
> conditions alongwith LOG.warn("CatalogJanitor disabled! Not running scan.")
> for better debugging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20302) CatalogJanitor should log the reason why it is disable
[
https://issues.apache.org/jira/browse/HBASE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20302:
--
Attachment: HBASE-20302.branch-1.v1.patch
> CatalogJanitor should log the reason why it is disable
> --
>
> Key: HBASE-20302
> URL: https://issues.apache.org/jira/browse/HBASE-20302
> Project: HBase
> Issue Type: Bug
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Major
> Attachments: HBASE-20302.branch-1.v1.patch
>
>
> when catalogJanitor is disabled it has various condition for which it can be
> true to disable CatalogJanitor and sends this message "CatalogJanitor
> disabled! Not running scan." Since this is an async thread, it is difficult
> to identify what is the exact reason for it disable. We could log all
> conditions alongwith LOG.warn("CatalogJanitor disabled! Not running scan.")
> for better debugging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20302) CatalogJanitor should log the reason why it is disable
Vishal Khandelwal created HBASE-20302:
-
Summary: CatalogJanitor should log the reason why it is disable
Key: HBASE-20302
URL: https://issues.apache.org/jira/browse/HBASE-20302
Project: HBase
Issue Type: Bug
Reporter: Vishal Khandelwal
Assignee: Vishal Khandelwal
when catalogJanitor is disabled it has various condition for which it can be
true to disable CatalogJanitor and sends this message "CatalogJanitor disabled!
Not running scan." Since this is an async thread, it is difficult to identify
what is the exact reason for it disable. We could log all conditions alongwith
LOG.warn("CatalogJanitor disabled! Not running scan.") for better debugging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20230) Incorrrect log message in RSRpcService
[
https://issues.apache.org/jira/browse/HBASE-20230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Khandelwal updated HBASE-20230:
--
Affects Version/s: 1.3.1
> Incorrrect log message in RSRpcService
> --
>
> Key: HBASE-20230
> URL: https://issues.apache.org/jira/browse/HBASE-20230
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Vishal Khandelwal
>Priority: Minor
>
> At RPCServices:3040, exception is thrown for version lesser 1.3 but check is
> for version 1.4
> VersionInfoUtil.hasMinimumVersion(context.getClientVersionInfo(), 1, 4)
> >> throw new UnknownScannerException("Throwing UnknownScannerException to
> >> reset the client"
> + " scanner state for clients older than 1.3.", e);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20230) Incorrrect log message in RSRpcService
Vishal Khandelwal created HBASE-20230:
-
Summary: Incorrrect log message in RSRpcService
Key: HBASE-20230
URL: https://issues.apache.org/jira/browse/HBASE-20230
Project: HBase
Issue Type: Bug
Reporter: Vishal Khandelwal
At RPCServices:3040, exception is thrown for version lesser 1.3 but check is
for version 1.4
VersionInfoUtil.hasMinimumVersion(context.getClientVersionInfo(), 1, 4)
>> throw new UnknownScannerException("Throwing UnknownScannerException to reset
>> the client"
+ " scanner state for clients older than 1.3.", e);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19108) Backups should understand the frequency of full and incremental backup
[ https://issues.apache.org/jira/browse/HBASE-19108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237083#comment-16237083 ] Vishal Khandelwal commented on HBASE-19108: --- This is not only about how the jobs for backup are triggered. These can be done cron or oozie. Here is the issue is backup process is unaware of couple of things 1. What is the expected frequency when full backup should run ? 2. What is the expected frequency when incremental should run ? 3. What are backups which can be deleted ? Above #1-#3 makes sure management of the backups for a longer run in production is easier. It is not in controller of a human to screw up something. Even if command is missed or triggered twice, there is no impact on the cluster. Take an example if full backup is triggered daily it would eat all space/if incremental backups jobs are not triggered it would not clear any WALs/management expiring the backup has high cost. Here ask is backup is aware what are frequencies it needs to run, when should it expire. so chances of corrupting or misusing anything in real cluster can be limited. > Backups should understand the frequency of full and incremental backup > -- > > Key: HBASE-19108 > URL: https://issues.apache.org/jira/browse/HBASE-19108 > Project: HBase > Issue Type: New Feature > Components: backup >Reporter: Vishal Khandelwal >Priority: Major > Labels: backup > > Backup scheduler which figures out tables for which backups are pending and > executes all required backups. > In case of failures, this automates required (full / incremental) backup > execution based on the set frequency. Thus the support to set frequency and > expire old backups should be added. This will reduce admin overhead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19109) Backup should provide and option to disable backup if full backups have started
[ https://issues.apache.org/jira/browse/HBASE-19109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16235241#comment-16235241 ] Vishal Khandelwal commented on HBASE-19109: --- [~vladmir]: This is not for within session but multiple sessions. Take an on day1 : We started full backup of Table : t1,t2,t3 . Then as per current design whenever incremental backup is triggered it will be t1,t2,t3 each time. In real prod usecase on day10 there are situations you do not want to continue running backup on for a table say t3. In current design, I do think that is possible. > Backup should provide and option to disable backup if full backups have > started > --- > > Key: HBASE-19109 > URL: https://issues.apache.org/jira/browse/HBASE-19109 > Project: HBase > Issue Type: New Feature > Components: backup > Environment: Ability to disable backups for a particular set of > tables if backups are started and property to enable it backup > Use disable / enable flag at table schema level , etc > These can be probable changes > * A new option/command line needs to added to enable/disable backups > * A new property and field to track list of disabled backup tables > * backupInfo.getTables() should have a logic to filter such disabled tables > * Hbase:backup table needs to have a flag for enable and disable backups > * During all table backups, backups for disabled table should not happen > * During full/incremental backup backups should error out for disabled table > if it is part of the list > * BackupInfo Table should have a list of disabled backups. > * If full backups is taken and backups are disabled then incremental backups > should not be performed > * If backups are enabled again, means full backups needs to be executed > before starting incremental backups > * Restore of disabled backups should not be stopped >Reporter: Vishal Khandelwal >Priority: Major > Labels: bac > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19108) Backups should understand the frequency of full and incremental backup
[ https://issues.apache.org/jira/browse/HBASE-19108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-19108: -- Description: Backup scheduler which figures out tables for which backups are pending and executes all required backups. In case of failures, this automates required (full / incremental) backup execution based on the set frequency. Thus the support to set frequency and expire old backups should be added. This will reduce admin overhead. was: Backup scheduler which figures out tables for which backups are pending and executes all required backups. In case of failures, this automates required (full / incremental) backup execution based on the set frequency. Thus the support to set frequency and expire old backups should be added. Thsi will reduce and admin overhead. > Backups should understand the frequency of full and incremental backup > -- > > Key: HBASE-19108 > URL: https://issues.apache.org/jira/browse/HBASE-19108 > Project: HBase > Issue Type: New Feature >Reporter: Vishal Khandelwal > Labels: backup > > Backup scheduler which figures out tables for which backups are pending and > executes all required backups. > In case of failures, this automates required (full / incremental) backup > execution based on the set frequency. Thus the support to set frequency and > expire old backups should be added. This will reduce admin overhead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19109) Backup should provide and option to disable backup if full backups have started
Vishal Khandelwal created HBASE-19109: - Summary: Backup should provide and option to disable backup if full backups have started Key: HBASE-19109 URL: https://issues.apache.org/jira/browse/HBASE-19109 Project: HBase Issue Type: New Feature Environment: Ability to disable backups for a particular set of tables if backups are started and property to enable it backup Use disable / enable flag at table schema level , etc These can be probable changes * A new option/command line needs to added to enable/disable backups * A new property and field to track list of disabled backup tables * backupInfo.getTables() should have a logic to filter such disabled tables * Hbase:backup table needs to have a flag for enable and disable backups * During all table backups, backups for disabled table should not happen * During full/incremental backup backups should error out for disabled table if it is part of the list * BackupInfo Table should have a list of disabled backups. * If full backups is taken and backups are disabled then incremental backups should not be performed * If backups are enabled again, means full backups needs to be executed before starting incremental backups * Restore of disabled backups should not be stopped Reporter: Vishal Khandelwal -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19108) Backups should understand the frequency of full and incremental backup
Vishal Khandelwal created HBASE-19108: - Summary: Backups should understand the frequency of full and incremental backup Key: HBASE-19108 URL: https://issues.apache.org/jira/browse/HBASE-19108 Project: HBase Issue Type: New Feature Environment: Backup scheduler which figures out tables for which backups are pending and executes all required backups. In case of failures, this automates required (full / incremental) backup execution based on the set frequency. Thus the support to set frequency and expire old backups should be added. Thsi will reduce and admin overhead. Reporter: Vishal Khandelwal -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19107) Backup should resume from last failed state
Vishal Khandelwal created HBASE-19107: - Summary: Backup should resume from last failed state Key: HBASE-19107 URL: https://issues.apache.org/jira/browse/HBASE-19107 Project: HBase Issue Type: New Feature Environment: Consider that incremental backup is happenng for 10 tables for a set of 100 WALs. if backup @ 10th fails, then on net iteration it would be triggered again from 100 WALs + new WALs all tables This is a issue because resource and time used to do he backup of 9 table & 100 WALs are wasted Rather it should have functionality to resume from previous state complete that backup and then do new set of WALs. This will make it more performant Reporter: Vishal Khandelwal -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18870) Hbase Backup should set the details to MR jobs
[ https://issues.apache.org/jira/browse/HBASE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219984#comment-16219984 ] Vishal Khandelwal commented on HBASE-18870: --- Thanks [~te...@apache.org] for review. Updated the patch after incorporating comments and removing the white space warning. > Hbase Backup should set the details to MR jobs > -- > > Key: HBASE-18870 > URL: https://issues.apache.org/jira/browse/HBASE-18870 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-18870.branch-2.v1.patch, > HBASE-18870.branch-2.v2.patch > > > For Incremental and Full Backups job names should be set correctly. It would > make the debug and monitoring better. > Current : > incremental -> WALPlayer_1506332227619 > ExportSnapshot-snapshot_1506323760362_default_t1 > Proposed : > incremental -> Backup_Incremental__ > Full -> Backups_Full__ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18870) Hbase Backup should set the details to MR jobs
[ https://issues.apache.org/jira/browse/HBASE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-18870: -- Attachment: HBASE-18870.branch-2.v2.patch > Hbase Backup should set the details to MR jobs > -- > > Key: HBASE-18870 > URL: https://issues.apache.org/jira/browse/HBASE-18870 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-18870.branch-2.v1.patch, > HBASE-18870.branch-2.v2.patch > > > For Incremental and Full Backups job names should be set correctly. It would > make the debug and monitoring better. > Current : > incremental -> WALPlayer_1506332227619 > ExportSnapshot-snapshot_1506323760362_default_t1 > Proposed : > incremental -> Backup_Incremental__ > Full -> Backups_Full__ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18870) Hbase Backup should set the details to MR jobs
[ https://issues.apache.org/jira/browse/HBASE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218449#comment-16218449 ] Vishal Khandelwal edited comment on HBASE-18870 at 10/25/17 11:54 AM: -- [~vladmir] please have a look at patch. was (Author: vishk): [~vladmir] > Hbase Backup should set the details to MR jobs > -- > > Key: HBASE-18870 > URL: https://issues.apache.org/jira/browse/HBASE-18870 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-18870.branch-2.v1.patch > > > For Incremental and Full Backups job names should be set correctly. It would > make the debug and monitoring better. > Current : > incremental -> WALPlayer_1506332227619 > ExportSnapshot-snapshot_1506323760362_default_t1 > Proposed : > incremental -> Backup_Incremental__ > Full -> Backups_Full__ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18870) Hbase Backup should set the details to MR jobs
[ https://issues.apache.org/jira/browse/HBASE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218449#comment-16218449 ] Vishal Khandelwal commented on HBASE-18870: --- [~vladmir] > Hbase Backup should set the details to MR jobs > -- > > Key: HBASE-18870 > URL: https://issues.apache.org/jira/browse/HBASE-18870 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-18870.branch-2.v1.patch > > > For Incremental and Full Backups job names should be set correctly. It would > make the debug and monitoring better. > Current : > incremental -> WALPlayer_1506332227619 > ExportSnapshot-snapshot_1506323760362_default_t1 > Proposed : > incremental -> Backup_Incremental__ > Full -> Backups_Full__ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18870) Hbase Backup should set the details to MR jobs
[ https://issues.apache.org/jira/browse/HBASE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-18870: -- Attachment: HBASE-18870.branch-2.v1.patch > Hbase Backup should set the details to MR jobs > -- > > Key: HBASE-18870 > URL: https://issues.apache.org/jira/browse/HBASE-18870 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-18870.branch-2.v1.patch > > > For Incremental and Full Backups job names should be set correctly. It would > make the debug and monitoring better. > Current : > incremental -> WALPlayer_1506332227619 > ExportSnapshot-snapshot_1506323760362_default_t1 > Proposed : > incremental -> Backup_Incremental__ > Full -> Backups_Full__ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18870) Hbase Backup should set the details to MR jobs
[ https://issues.apache.org/jira/browse/HBASE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Khandelwal updated HBASE-18870: -- Fix Version/s: 2.0.0 Status: Patch Available (was: Open) > Hbase Backup should set the details to MR jobs > -- > > Key: HBASE-18870 > URL: https://issues.apache.org/jira/browse/HBASE-18870 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Vishal Khandelwal >Assignee: Vishal Khandelwal >Priority: Minor > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-18870.branch-2.v1.patch > > > For Incremental and Full Backups job names should be set correctly. It would > make the debug and monitoring better. > Current : > incremental -> WALPlayer_1506332227619 > ExportSnapshot-snapshot_1506323760362_default_t1 > Proposed : > incremental -> Backup_Incremental__ > Full -> Backups_Full__ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
