[ 
https://issues.apache.org/jira/browse/HBASE-20713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16578811#comment-16578811
 ] 

stack commented on HBASE-20713:
-------------------------------

You are right [~zghaobac]. Rare is the case of a three-tiered Procedure but 
possible (I seem to remember we have at least one instance but can't recall at 
the moment).

> Revisit why to removeFromRunQueue in MasterProcedureExecutor's doPoll method 
> -----------------------------------------------------------------------------
>
>                 Key: HBASE-20713
>                 URL: https://issues.apache.org/jira/browse/HBASE-20713
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Guanghao Zhang
>            Priority: Major
>             Fix For: 2.0.2
>
>
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureScheduler.java#L210
> {code:java}
>     if (rq.isEmpty() || xlockReq) {
>       removeFromRunQueue(fairq, rq);
>     } else if (rq.getLockStatus().hasParentLock(pollResult)) {
>       // if the rq is in the fairq because of runnable child
>       // check if the next procedure is still a child.
>       // if not, remove the rq from the fairq and go back to the xlock state
>       Procedure<?> nextProc = rq.peek();
>       if (nextProc != null && !Procedure.haveSameParent(nextProc, 
> pollResult)) {
>         removeFromRunQueue(fairq, rq);
>       }
>     }
> {code}
> Here is the comment of why to remove from run queue. If I am not wrong, 
> here's assumption is the parent procedure should require exclusive lock. So 
> if the nextProc is a child but has different parent with current procedure, 
> we can remove it from run queue.
> But there maybe three type procedure. Procedure A's child is Procedure B. 
> Procedure's child is Procedure C. And only Procedure A need exclusive lock 
> and Procedure B,C don't require exclusive lock. The 
> condition(!Procedure.haveSameParent(nextProc, pollResult)) is not right for 
> this case?
> FYI [~stack]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to