[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[ https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943389#comment-16943389 ] Sakthi commented on HBASE-21292: This went into branch-1,1.4 & 1.3 as well. Updating the fix versions. > IdLock.getLockEntry() may hang if interrupted > - > > Key: HBASE-21292 > URL: https://issues.apache.org/jira/browse/HBASE-21292 > Project: HBase > Issue Type: Bug >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21292.branch-2.0.001.patch, > HBASE-21292.branch-2.0.002.patch > > > This is a rare case found by my colleague which really happened on our > production env. > Thread may hang(or enter a infinite loop ) when try to call > IdLock.getLockEntry(). Here is the case: > 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting > for it. > 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but > since Thread2 was waiting, it won't call map.remove(entry.id) > 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no > one will remove this IdLock from the map. > 4. If another thread try to call getLockEntry on this IdLock， it will end up > in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) != > null and existing.locked=false > It is hard to write a UT since it is a very rare race condition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917652#comment-16917652
]
Hudson commented on HBASE-21292:
Results for branch branch-1.3
[build #944 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/944/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/944//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/944//console].
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- Something went wrong running this stage, please [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/944//console].
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[ https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917415#comment-16917415 ] Hudson commented on HBASE-21292: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #631 (See [https://builds.apache.org/job/HBase-1.3-IT/631/]) HBASE-22706 Backport HBASE-21292 to branch-1 (apurtell: rev ca5c63486e5d8e1e0e8535ad478bfb896b23d0e4) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/util/IdLock.java > IdLock.getLockEntry() may hang if interrupted > - > > Key: HBASE-21292 > URL: https://issues.apache.org/jira/browse/HBASE-21292 > Project: HBase > Issue Type: Bug >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21292.branch-2.0.001.patch, > HBASE-21292.branch-2.0.002.patch > > > This is a rare case found by my colleague which really happened on our > production env. > Thread may hang(or enter a infinite loop ) when try to call > IdLock.getLockEntry(). Here is the case: > 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting > for it. > 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but > since Thread2 was waiting, it won't call map.remove(entry.id) > 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no > one will remove this IdLock from the map. > 4. If another thread try to call getLockEntry on this IdLock， it will end up > in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) != > null and existing.locked=false > It is hard to write a UT since it is a very rare race condition. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917136#comment-16917136
]
Hudson commented on HBASE-21292:
Results for branch branch-1.4
[build #983 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/983/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/970//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/978//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917130#comment-16917130
]
Hudson commented on HBASE-21292:
Results for branch branch-1
[build #1033 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/1033/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/1011//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/1024//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/1028//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657054#comment-16657054
]
Hudson commented on HBASE-21292:
Results for branch master
[build #555 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/555/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/555//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/555//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/555//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for
details|https://builds.apache.org/job/HBase%20Nightly/job/master/555//artifact/output-integration/hadoop-2.log].
(note that this means we didn't run on Hadoop 3)
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656371#comment-16656371
]
Hudson commented on HBASE-21292:
Results for branch branch-2
[build #1410 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1410/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1410//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1410//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1410//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656212#comment-16656212
]
Hudson commented on HBASE-21292:
Results for branch branch-2.1
[build #486 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/486/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/486//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/486//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/486//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656182#comment-16656182
]
Hudson commented on HBASE-21292:
Results for branch branch-2.0
[build #971 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/971/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/971//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/971//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/971//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> IdLock.getLockEntry() may hang if interrupted
> -
>
> Key: HBASE-21292
> URL: https://issues.apache.org/jira/browse/HBASE-21292
> Project: HBase
> Issue Type: Bug
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21292.branch-2.0.001.patch,
> HBASE-21292.branch-2.0.002.patch
>
>
> This is a rare case found by my colleague which really happened on our
> production env.
> Thread may hang(or enter a infinite loop ) when try to call
> IdLock.getLockEntry(). Here is the case:
> 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting
> for it.
> 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but
> since Thread2 was waiting, it won't call map.remove(entry.id)
> 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no
> one will remove this IdLock from the map.
> 4. If another thread try to call getLockEntry on this IdLock， it will end up
> in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) !=
> null and existing.locked=false
> It is hard to write a UT since it is a very rare race condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[ https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656135#comment-16656135 ] Allan Yang commented on HBASE-21292: Will file another issue for backporting, thanks for committing the patch, [~stack]. > IdLock.getLockEntry() may hang if interrupted > - > > Key: HBASE-21292 > URL: https://issues.apache.org/jira/browse/HBASE-21292 > Project: HBase > Issue Type: Bug >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3 > > Attachments: HBASE-21292.branch-2.0.001.patch, > HBASE-21292.branch-2.0.002.patch > > > This is a rare case found by my colleague which really happened on our > production env. > Thread may hang(or enter a infinite loop ) when try to call > IdLock.getLockEntry(). Here is the case: > 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting > for it. > 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but > since Thread2 was waiting, it won't call map.remove(entry.id) > 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no > one will remove this IdLock from the map. > 4. If another thread try to call getLockEntry on this IdLock， it will end up > in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) != > null and existing.locked=false > It is hard to write a UT since it is a very rare race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655297#comment-16655297
]
Hadoop QA commented on HBASE-21292:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
8s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
20s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
53s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
56s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 42s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.5
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
10s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 32m 23s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-21292 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12944539/HBASE-21292.branch-2.0.002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux f3005dc661f6 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.0 / 9cc5f86e8f |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/14743/testReport/ |
| Max. process+thread count | 305 (vs. ulimit of 1) |
| modules | C: hbase-common U: hbase-common |
| Console output |
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[ https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646866#comment-16646866 ] stack commented on HBASE-21292: --- +1 Its for sure exotic. > IdLock.getLockEntry() may hang if interrupted > - > > Key: HBASE-21292 > URL: https://issues.apache.org/jira/browse/HBASE-21292 > Project: HBase > Issue Type: Bug >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 2.1.0, 2.0.2, 1.4.9 > > Attachments: HBASE-21292.branch-2.0.001.patch > > > This is a rare case found by my colleague which really happened on our > production env. > Thread may hang(or enter a infinite loop ) when try to call > IdLock.getLockEntry(). Here is the case: > 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting > for it. > 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but > since Thread2 was waiting, it won't call map.remove(entry.id) > 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no > one will remove this IdLock from the map. > 4. If another thread try to call getLockEntry on this IdLock， it will end up > in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) != > null and existing.locked=false > It is hard to write a UT since it is a very rare race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[
https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646428#comment-16646428
]
Hadoop QA commented on HBASE-21292:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
36s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
30s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
3s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
8s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
25s{color} | {color:red} hbase-common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 25s{color}
| {color:red} hbase-common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
24s{color} | {color:red} hbase-common: The patch generated 3 new + 0 unchanged
- 0 fixed = 3 total (was 0) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
16s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 37s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.5
2.7.4 or 3.0.0. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
58s{color} | {color:red} hbase-common generated 2 new + 0 unchanged - 0 fixed =
2 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
47s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 51s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-common |
| | IdLock$Entry is incompatible with expected argument type Long in
org.apache.hadoop.hbase.util.IdLock.getLockEntry(long) At IdLock.java:argument
type Long in org.apache.hadoop.hbase.util.IdLock.getLockEntry(long) At
IdLock.java:[line 92] |
| | IdLock$Entry is incompatible with expected argument type Long in
org.apache.hadoop.hbase.util.IdLock.tryLockEntry(long, long) At
IdLock.java:argument type Long in
org.apache.hadoop.hbase.util.IdLock.tryLockEntry(long, long) At
IdLock.java:[line 152] |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-21292 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12943425/HBASE-21292.branch-2.0.001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
|
[jira] [Commented] (HBASE-21292) IdLock.getLockEntry() may hang if interrupted
[ https://issues.apache.org/jira/browse/HBASE-21292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646408#comment-16646408 ] Ted Yu commented on HBASE-21292: Good catch. For the second hunk, would it be more readable if the handling is moved to finally block ? > IdLock.getLockEntry() may hang if interrupted > - > > Key: HBASE-21292 > URL: https://issues.apache.org/jira/browse/HBASE-21292 > Project: HBase > Issue Type: Bug >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Fix For: 2.1.0, 2.0.2, 1.4.9 > > Attachments: HBASE-21292.branch-2.0.001.patch > > > This is a rare case found by my colleague which really happened on our > production env. > Thread may hang(or enter a infinite loop ) when try to call > IdLock.getLockEntry(). Here is the case: > 1. Thread1 owned the IdLock, while Thread2(the only one waiting) was waiting > for it. > 2. Thread1 called releaseLockEntry, it will set IdLock.locked = false, but > since Thread2 was waiting, it won't call map.remove(entry.id) > 3. While Thread1 was calling releaseLockEntry, Thread2 was interrupted. So no > one will remove this IdLock from the map. > 4. If another thread try to call getLockEntry on this IdLock， it will end up > in a infinite loop. Since existing = map.putIfAbsent(entry.id, entry)) != > null and existing.locked=false > It is hard to write a UT since it is a very rare race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
