1. what i understanding is, about this feature, it just an on-off switch on 'dependent node' wait the unready dependent tasks.
2. whether a value setting attribute for delay execution is more suitable, then the task can wait for a time before running. at the same time, this feature can be applied to all the tasks. wu shaoj <[email protected]> 于2020年7月9日周四 下午2:15写道： > Solution A is better > > On 2020/7/9, 13:24, "wang" <[email protected]> wrote: > > 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。 > -- DolphinScheduler(Incubator) PPMC BaoLiang 鲍亮 [email protected]
