[
https://issues.apache.org/jira/browse/HBASE-21384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663699#comment-16663699
]
Hudson commented on HBASE-21384:
--------------------------------
Results for branch master
[build #567 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/567/]: (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/567//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/567//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/567//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Procedure with holdlock=false should not be restored lock when restarts
> ------------------------------------------------------------------------
>
> Key: HBASE-21384
> URL: https://issues.apache.org/jira/browse/HBASE-21384
> Project: HBase
> Issue Type: Sub-task
> Reporter: Allan Yang
> Assignee: Allan Yang
> Priority: Blocker
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21384.branch-2.0.001.patch,
> HBASE-21384.branch-2.0.002.patch, HBASE-21384.branch-2.0.003.patch
>
>
> Yet another case of stuck similar with HBASE-21364.
> The case is that:
> 1. A ModifyProcedure spawned a ReopenTableProcedure, and since its
> holdLock=false, so it release the lock
> 2. The ReopenTableProcedure spawned several MoveRegionProcedure, it also has
> holdLock=false, but just after it store the children procedures to the wal
> and begin to release the lock, the master was killed.
> 3. When restarting, the ReopenTableProcedure's lock was restored (since it
> was hold the lock before, which is not right, since it is in WAITING state
> now and its holdLock=false)
> 4. After restart, MoveRegionProcedure can execute since its parent has the
> lock, but when it spawned the AssignProcedure, the AssignProcedure procedure
> can't execute anymore, since it parent didn't have the lock, but its
> 'grandpa' - ReopenTableProcedure has.
> 5. Restart the master, the stuck still, because we will restore the lock for
> ReopenTableProcedure.
> Two fixes:
> 1. We should not restore the lock if the procedure doesn't hold lock and in
> WAITING state.
> 2. Procedures don't have lock but its parent has the lock should also be put
> in front of the queue, as a addendum of HBASE-21364.
> Discussion:
> Should we check the lock of all ancestors not only its parents? As addressed
> in the comments of the patch, currently, after fix the issue above, check
> parent is enough.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
