I think, Is there a node that simply waits for a period of time before executing?
-------------------- DolphinScheduler(Incubator) Commtter Hemin Wen 温合民 [email protected] -------------------- wang <[email protected]> 于2020年7月9日周四 下午1:24写道： > Dependency node new feature: Wait for the dependency to start > Current Features > > When the current dependent node executes, if it is found that the > dependent task node has not started to execute, the node will be directly > judged as a failure. > > New Feature Target > > When the execution reaches the dependent node, if there is no ready in the > list of dependent task nodes, the node will wait for a while. If the > dependent task nodes are started within the waiting time, execution > continues; otherwise, the node fails to execute. > > Plan > Plan A > > By using the existing timeout judgment mechanism, waiting for the > dependent node to start and waiting for the dependent node to complete is > regarded as an equivalent state, so as to achieve the goal. In the original > mechanism, if the timeout attribute is not set, then a dependent task node > will wait indefinitely until it is completed when the task node has been > started; if the timeout attribute is set, then the waiting time is limited . > > If this scheme is used, the new dependent node will exhibit the following > behavior: > > If the timeout attribute is not set: > > If the dependent node finds that the dependent task node has not started, > the dependent node will wait indefinitely for it to start (the original one > failed directly); > The behavior of the dependent task node that has been started is the same > as before. > > If the timeout attribute is set: > > If the dependent node finds that the dependent task node has not started, > the dependent node will wait for it to start for a period of time, and if > the wait times out, it will be treated the same as the dependent task > running timeout; > The behavior of the dependent task node that has been started is the same > as before. > > Program advantages: > > Simple implementation, less code changes, and even the front end can be > left unchanged. > > Disadvantages: > > Cannot distinguish between two concepts of waiting to start and waiting to > complete (question: is it important for users to distinguish these two > concepts?) > Plan B > > A special delay-waiting attribute is added for dependent nodes. Although > this attribute is called "delay-waiting", it is closer to the "timeout > setting" at the conceptual level. > > Program advantages: > > Simpler, less code changes; > Ability to set supermarket time separately for waiting for dependency > start and waiting for completion. > > Disadvantages: > > The two attributes are similar in concept and appear redundant in design. > At last > > For the above problem, the dependent task node is not started, is > executing but timed out, and failed to run. I think they are all the > reasons for the dependent node execution failure, and there is no obvious > difference between them. > > I personally prefer Plan A. > > 依赖节点新特性：延时等待 > 目前特点 > > 当前依赖节点执行时，若发现被依赖任务节点尚未开始执行，该节点就会被直接判为失败。 > > 新特性目标效果 > > > 当执行到依赖节点时，若被依赖的任务节点列表中存在没有就绪的，那么该节点会等待一段时间。若果等待时间内被依赖任务节点都启动了，就继续执行；否则该节点执行失败。 > > 实现方案 > 方案A > > > 利用已有的超时判断机制，将等待被依赖节点启动和等待被依赖节点完成视为等价的状态，从而达到目标。在原有的机制中，如果没有设置超时属性，那么一个被依赖任务节点在已经启动的情况下，依赖节点会无限期地等待直到它完成；如果设置了超时属性，那么这个等待时间就有了限制。 > > 如果使用这个方案，那么新的依赖节点将会表现出以下行为： > > 如果没有设置超时属性： > > 如果依赖节点发现被依赖任务节点没有启动，依赖节点会无限期地等待它启动（原来的是直接失败）； > 对于已经启动的被依赖任务节点，行为与以往相同。 > > 如果设置了超时属性： > > 如果依赖节点发现被依赖任务节点没有启动，依赖节点会在一段时间内地等待它启动，如果等待超时了，将与被依赖任务运行超时同等对待； > 对于已经启动的被依赖任务节点，行为与以往相同。 > > 方案优点： > > 实现简单，代码改动少，前端甚至可以不改。 > > 缺点： > > 前端同学可能会失业； > 不能够区分等待启动和等待完成两个概念（疑问：对于用户来说区分这两个概念重要吗？） > 方案B > > 为依赖节点专门新增一个延时等待的属性，这个属性虽然叫做“延时等待”，但它在概念层面上与“超时设置”更加贴近。 > > 方案优点： > > 较为简单，代码改动少； > 能够单独为等待依赖启动和等待依赖完成设置超市时间。 > > 缺点： > > 两个属性概念上雷同，显得设计冗余。 > 最后 > > 对于上面的问题，我认为被依赖任务节点未启动、正在执行但超时、运行失败都是依赖节点执行失败的原因，它们并没有明显的区别。 > > 我个人倾向于方案A。
