海豚调度调优 | 如何解决任务被禁用出现的Bug

💡  本系列文章是 DolphinScheduler 由浅入深的教程,涵盖搭建、二开迭代、核心原理解读、运维和管理等一系列内容。适用于想对 DolphinScheduler了解或想要加深理解的读者。

祝开卷有益。

本系列教程基于 DolphinScheduler 2.0.5 做的优化。(稳定版推荐使用3.1.9

上篇回顾:海豚调度调优 | 正在运行的工作流(DAG)如何重新拉起失败的任务(Task)

最近调度稳定运行一段时间了,有时间分享一下我们在使用海豚调度过程中遇到的问题和使用经验,希望可以帮到大家。

今天分享的是任务被禁用出现的 Bug,包含两相关联的问题。

已有的功能:在一个 DAG(工作流)中,存在节点被禁用的情况,表示该节点不会执行,执行到这个节点的时候,可以跳过这个节点继续执行下游节点。

问题1[1]:在 Version 2.0.1 中,存在一个 BUG,如下图所示,有 6 个节点,其中 test1_stop 和 test2_stop 节点是被禁用的。

从上图可以看出,test3 依赖 test1_stop 和 test2_stop。但是执行的时候,发现 test2 节点还在运行呢,test3 就已经执行了,并没有等待所有上游节点运行结束

上述问题如何解决呢?

新增一个递归向上查找间接依赖的方法(如果是上游节点被禁用了,继续向上查找)

新增 setIndirectDepList 方法,如果该节点的上游被禁用了,则继续寻找上游。最终把所有的上游加到 indirectDepCodeList 这里。

/**
 * This function is specially used to handle the dependency situation where the parent node is a prohibited node.
 * When the parent node is a forbidden node, the dependency relationship should continue to be traced
 *
 * @param taskCode            taskCode
 * @param indirectDepCodeList All indirectly dependent nodes
 */
private void setIndirectDepList(String taskCode, List<String> indirectDepCodeList) {
    TaskNode taskNode = dag.getNode(taskCode);
    List<String> depCodeList = taskNode.getDepList();
    for (String depsNode : depCodeList) {
        if (forbiddenTaskMap.containsKey(depsNode)) {
            setIndirectDepList(depsNode, indirectDepCodeList);
        } else {
            indirectDepCodeList.add(depsNode);
        }
    }
}

在 isTaskDepsComplete 方法中,引用这个 list ,遍历。

好的,问题1[1]到这里就结束了,修复之后,test3 的直接上游节点 test2_stop 被禁用时,会继续往上找到 test2, 如果 test2 还在运行,test3 不会立刻运行。

**负杂的系统,随着不断迭代,总会伴随着小"惊喜"。继续往下看 **

上述新增的逻辑,带来了问题2[2],请看下图:运行test_del_node 节点,选择向后执行,按照正常的逻辑,会运行 test_del_node 和 test_del_node_36j 这两个节点。但是 test_del_node_36j 一直不执行。

查看 Master 日志发现,在提交 test_del_node_36j 这个节点的时候,出现了submit standby task error这个错误,拿到本地 debug 之后,发现在 setIndirectDepList 中出现了 NPE。最后定位到下面两行代码:

TaskNode taskNode = dag.getNode(taskCode);
List<String> depCodeList = taskNode.getDepList();

通过分析,最后发现是因为test_del_node_36j的节点的直接上游节点被禁用了,按照 setIndirectDepList 里面的逻辑,存在被禁用的节点,是会继续往上找的,找到间接依赖。

dag 在工作流启动的时候,根据 startNode 生成了关系图(dag),dag 里面只有两个节点: test_del_node 和 test_del_node_36j 。此时递归查找test_del_node_36j上游节点的上游节点的时候,报了 NEP。

处理方式也比较简单,加一个 null 的判断。

这样,问题2[2]就解决了。

总结

  • 问题1 在 2.0.3-release 中得到修复。

  • 问题2 在 3.0.5-release 中得到修复。

如果不想升级的小伙伴,可以自行根据自己的版本,进行修改。

需要注意的是:

  • 2.x 版本,对应的代码文件是 WorkflowExecuteThread.java

  • 3.x 版本,对应的代码文件是 WorkflowExecuteRunnable.java

以上就是任务被禁用出现的Bug关联的两个问题的分享,如果有任何疑问,都可以与我交流,同样社区也推荐大家使用3.1.9版本,这是相对比较稳定的版本,上文中,还提到了 dag 的生成,下次接着讲,希望可以帮到你。

本文由 白鲸开源 提供发布支持!

热门相关:隐婚101天:唐少宠妻成瘾   巨星小甜妻:前夫,请出局   我真不是开玩笑   汉阙   呆萌配腹黑:倒追男神1000次