【发布时间】：2018-04-21 10:19:37
【问题描述】：
背景：
在我们典型的状态机工作模型中，我们使用状态机来监控由spring cloud stream微服务完成的spring-batch处理。 更准确地说，我们创建了一个名为 ItemStream 的流，部署了源、进程、接收器微服务，用于批量读取、处理和写入记录；分别 。 在执行这些活动时，我们会触发 REST 调用，每个调用由流操作之间的一个事件组成。我们在状态机微服务中使用这些 REST 调用，并在机器实例上相应地触发这些事件。在状态机级别，每次处理完成后，我们使用 JPA/Redis 状态机持久性将状态机上下文持久化到持久存储（数据库/Redis 缓存）。 当从流中接收到新的 REST 调用时，我们从持久存储中恢复机器上下文并用它填充一个新的状态机对象；以便准备新的机器对象以具有以前存在的机器状态。 注意：这里的“填充新的状态机对象”只是意味着我们每次使用机器工厂调用创建新实例，因为我们还没有插入机器对象池实现来推送和弹出 StateMachine 的已使用对象在需要时，而不是每次都创建新的实例。
问题：
然而，现在我们面临的问题是，我们已经在 uml 文件中为特定状态（例如状态 PROCESSEDCHUNK ）配置了延迟事件（例如，CompleteChunk_1 ）。 现在，当机器处于 PROCESSEDCHUNK 状态时触发 CompleteChunk_1 事件后，此事件确实会延迟，即正确停放在一边。现在预计机器应该在到达特定的未来状态（即 WRITECHUNK ）时自行触发这个停放的事件，该事件在转换中被映射。 但是，一旦机器达到该状态，即 WRITECHUNK 状态，机器就不会自行触发之前停在机器延迟列表中的 CompleteChunk_1 事件。
观察
**1.**在解决问题后，我注意到状态机的成员属性“stateMachineExecutor”包含 DefaultStateMachineExecutor 实例，该实例在自身内部的数据结构“ConcurrentLinkedList”中维护延迟列表。这个执行程序每次都在 AbstractStateMachine 类的状态机的 onInit() 方法中实例化为新的执行程序。因此，我相信每当从工厂创建新实例并且使用先前的持久上下文恢复机器对象时，我们都会丢失停在该执行程序的 "deferredList" 中的延迟事件。因为 OOB 持久化/恢复不会持久化/恢复执行器的状态，因此该执行器上存在的延迟列表将丢失。 因此，在我们的案例中，当机器进入正确状态时，即 WRITECHUNK 时，执行程序已经丢失了停在过去事件调用中的延迟事件。因此它们现在不能被机器自动触发，因为执行器中现在不存在停放的事件。
**2.**在 spring 文档中给出的简单状态机示例中，我尝试配置延迟事件并且它正常工作，并且在达到有效状态后，停放的事件确实会自动触发。在这些示例中，状态机从第一个事件到最后一个事件一直启动并运行。因此，机器的相同实例对象持有相同的 DefaultStateMachineExecutor 实例直到结束。
3.Maven依赖库版本如下：
a.spring-statemachine-core：2.0.0 b.spring-statemachine-uml：2.0.0
请求解决方案 ??
那么在查看我们持久化上下文并在收到的每个 REST 调用时恢复它的事实时，是否需要任何设计更改或处理这种 DefaultStateMachineExecutor 情况的方法？或者我错过了关于我在故障排除时得出的上述结论的理解？？
提前致谢。
【问题讨论】：
标签： deferred state-machine executor spring-statemachine