ytyht226

> ``` > 1：源码 > ``` > > //OP监听器--成功 if (wrapper.getListener(OperatorEventEnum.SUCCESS) != null) { wrapper.getListener(OperatorEventEnum.SUCCESS).forEach(t -> ((OperatorListener)t).onEvent(wrapper, OperatorEventEnum.SUCCESS)); } wrapper.getOperatorResult().setResult(operatorResult); > > 2：修改后 wrapper.getOperatorResult().setResult(operatorResult); //OP监听器--成功 if (wrapper.getListener(OperatorEventEnum.SUCCESS) != null) {...

> 循环节点应该如何编排？ 是说某个节点需要执行多次？目前引擎在编排层面不支持这种方式，不过你可以在op的具体实现里面控制循环的次数。另外，循环节点的使用场景可以举例说明一下么，我看看后续版本是否需要支持？

> > > 循环节点应该如何编排？ > > > > > > 是说某个节点需要执行多次？目前引擎在编排层面不支持这种方式，不过你可以在op的具体实现里面控制循环的次数。另外，循环节点的使用场景可以举例说明一下么，我看看后续版本是否需要支持？ > > 是的。比如不断判断某个节点的返回数据是否有值，如果还有值，则参数+1后继续执行该节点，直到取出所有数据。比如某个http调用是需要分页，不断查询的 除了上面说的可以直接在op逻辑内部实现循环控制次数，还可以结合op的回调接口实现，下面是一个例子，可以参考： **CycleTest代码实现：** **Operator1代码实现：** **Operator2代码实现：**

> > next的下个节点，加了judge是false的也会执行，是否有问题 > > ``` > @Test > public void test2() { > DagEngine engine = new DagEngine(executor); > int param = 1; > OperatorWrapper wrapper1 = new OperatorWrapper()...

嗯，现状是会重复解析，可以做个压测看看，jsonpath解析的性能怎么样；下个版本考虑优化一下

嗯 之前有规划通过json配置文件解析DAG节点依赖，因时间关系还没来得及实现 ---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 日期 | 2025年05月28日 10:06 | | 收件人 | ***@***.***> | | 抄送至 | ***@***.***> | | 主题 | Re:...

> > > 嗯 之前有规划通过json配置文件解析DAG节点依赖，因时间关系还没来得及实现 > > > […](#) > > > > > > 请问今年有改排期计划吗,我是一枚java开发仔,可提供协助 > > 大佬，请问你实现这个功能了么 这段时间有点忙，这个功能还没实现，过段时间有空开发一下

没太理解问题，是中断引擎还是某个节点的执行？能说下具体的场景么？

> > 没太理解问题，是中断引擎还是某个节点的执行？能说下具体的场景么？ > > 整个任务有多个节点，每个节点执行的时间较长。所以启动的时候会用异步来启动任务。 有时候会需要中断这个任务的执行，手动来停止。任务里面正在执行的节点中断，未执行的节点跳过。 但是需要任务的after 这些回调正常执行。 明白了使用场景，目前对于异步启动的任务还不支持主动进行停止，下个版本增加这个功能

> 优化建议 1.简化引擎构建的节点类,可以把operator和wrapper合并成一个类 2.现在对子引擎支持不太好,在节点中执行子引擎会导致父引擎的节点执行结果丢失 > > 其他建议: 1.添加节点并行监听事件 感谢提出建议~ 优化建议1：operator是一个接口，业务实现改接口，编写具体的业务逻辑；wrapper用来描述节点（operator）之间的依赖关系；理论上使用taskflow时，业务不需要关注wrapper，只不过现在是通过编码的方式来指定节点之间的依赖关系，后面会提供根据配置指定依赖关系，wrapper对使用方无感知；operator（算子）是可以复用的，如果和wrapper合并成一个类，就不太能复用了。 优化建议2：指的是DAG中嵌套DAG？目前还没考虑这种使用场景。使用节点组是否可以实现类似功能 "添加节点并行监听事件"：没太明白使用场景，可以详述一下~