Yukino
Yukino
native 的话，server 就按 SpringBoot 的方式去打，worker 被集成，原来项目怎么打还是怎么打
官方的 Processor 不支持的部分，可以考虑自己扩展写一些 processor
1. 稳定复现吗？ 2. 如果稳定复现，请提供使用的 PowerJob 的版本和Java版本
估计是 AKKA 部分通讯有问题，由于 akka 后续的收费策略，这个协议目前只是为了兼容低版本存在。 不过下个版本应该还是会看下怎么 fix。 建议大家直接用 HTTP 协议～ HeZhanfeng ***@***.***> 于2024年1月29日周一 14:32写道： > 同样的问题，作者还解决么？ > > — > Reply to this email directly, view it on GitHub >...
目前还不支持，后续会支持下
我在你的 issue 回复问题的原因了，其实 server 的逻辑是没有问题的，所以不能去调整这个顺序。 事实上这个顺序也是精心设计的。 server 为了保证“至少调度一次”，一定需要先执行调度，再写表。这样假如调度失败，无法完成写表，就会有后续的容灾机制触发重调度。 假如先写了表，此事系统重启或者异常导致调度未执行，那状态就出错了。
好的，感谢反馈，后续我们确认下问题是否存在。
从设计上讲你描述的方式确实更加解耦。 但实际开发过程中，从我的视角看，一般情况下子任务的拆解本身也是业务逻辑的一部分。不同的任务一般都会有自己的拆解逻辑和处理逻辑，如果分拆接口和实现，可能反而会导致开发成本的上升。 你可以举个更具体的、分拆后有明显受益的例子让我更有体感一些，哈哈～
嗯，其实我一开始也想过设计这样的接口，应该和你想象的一样，分解出 Map 、 Process 和 reduce 3 个过程： ```java List map(TaskContext ctx); ProcessResult process(TaskContext context); ProcessResult reduce(TaskContext context, List taskResults) ``` 但是这组接口带来的问题是他强制限定了 2 级 的 map，无法实现 map -> process ->...
这个其实是不是自己在业务层面也可以封装下🤔️，搞个抽象类之类的应该可以🤔️