People could come to rely on the order.
The reason I suggested you should rely on the queue being empty to break
the loop instead of getting the number of elements at the start is to avoid
falling off the end of the queue in the presence of multiple threads.
On Sat, Dec 1, 2018, 1:44 AM 张铎(Duo Zh
I think it is fine to keep the current implementation? What is the problem
if we schedule in reverse order? We do not guarantee any order when
executing the sub procedures...
Misty Linville 于2018年12月1日周六 下午1:56写道：
> I like your solution in principle, but I think it would be better to loop
> unti
I like your solution in principle, but I think it would be better to loop
until the queue reports that it's empty.
On Wed, Nov 28, 2018, 8:18 PM OpenInx Thanks Allan's reply
>
> So if we can ensure that all children are independent, then it won't be a
> problem.
> But the reversed shcedule order
Thanks Allan's reply
So if we can ensure that all children are independent, then it won't be a
problem.
But the reversed shcedule order is some counterintuitive. I think a minor
change can
help fix this:
diff --git
a/hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/ProcedureExec
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
indepen
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 fram
