Yes, you are right, every procedure will be add to front, so the final execution order may be reversed, But actually, there will be more than one worker threads, so likely, they will be executed at the same time. I think the design is unintentionally, since all the child procedure should be independent and won't depend on each other, so they can be executed at any order. And more, after HBASE-21375 <https://issues.apache.org/jira/browse/HBASE-21375> checked in all 2.x branch, the worker thread will execute every possible procedure in the queue, so the front ones won't block, so this won't be a problem. Best Regards Allan Yang
OpenInx <open...@gmail.com> 于2018年11月28日周三 下午10:42写道： > Hi : > > I read parts of the procedure v2 framework, and found that if a procedure > has 3 added child procedure, > then it's children will be schedued in the reversed order. > > Let me give an example. if a procedure A added 3 child procedure: B, C , > D. > > a.addChildProcedure(B, C, D) > > The procedure framework will add the B,C,D child produre in a dequeue to > schedule > > ( Code Path --- ProcedureExecutor#execProcedure > -- submitChildrenProcedures -- dequeue#addFront ) > > So the dequeue will be : (front) D, C, B (back) > > Then we will poll each procedure from the dequeue, and dispatch to the > executor to run .. > > In the final, the procedure executing order will be : D, C, B, which is > the revered order compared to the addChildProcedure order. > > My question is : is it designed intentionally ? Or unintentionally doing > the wrong implementation ? > > Seems most the child procedure are region assign or unassign, looks like no > problem now.. > > Please correct me if I am wrong or missing something. > > Thanks. >
