DefaultStateMachineExecutor中维护的延迟事件列表在spring状态机

时间:2018-04-21 10:19:38

标签: deferred state-machine executor spring-statemachine

背景

在我们典型的状态机工作模型中,我们使用状态机来监控弹簧云流微服务所完成的弹簧批处理。 更确切地说,我们创建了一个名为ItemStream的流,其中部署了源,进程,接收微服务,可以批量读取,处理和写入记录;分别 。 在执行这些活动时,我们触发REST调用,每个调用由流操作之间的一个事件组成。我们在State Machine微服务中使用这些REST调用,并在机器实例上相应地触发这些事件。这里在状态机级别每次处理完成后,我们使用JPA / Redis State Machine Persister将状态机上下文持久化到持久性存储(database / Redis缓存)。 当从流接收到新的REST调用时,我们从持久存储中恢复机器上下文并用它填充一个新的状态机对象;以便使新机器对象具有先前存在的机器状态。 注意:此处'填充新状态机对象'只是意味着我们每次使用机器工厂调用创建新实例,因为我们还没有插入机器对象池实现来在需要时推送和弹出StateMachine的使用对象,而不是每次都创建新的实例。

问题:

然而,现在我们面临的问题是,我们已经为uml文件中的特定状态(例如,状态PROCESSEDCHUNK)配置了延迟事件(例如,对于例如PerfectChunk_1)。 现在,当机器处于PROCESSEDCHUNK状态时触发CompleteChunk_1事件后,此事件确实被延迟,即正确停放在一旁。现在预计机器应该在达到该事件在转换中映射的特定未来状态(即WRITECHUNK)时自动触发该停放事件。 但是一旦机器达到该状态,即处于WRITECHUNK状态,机器就不会自行触发那个先前停在机器延期列表中的CompleteChunk_1事件。

观察

** 1。**在解决问题之后,我注意到的是State machine的会员财产' stateMachineExecutor'保存DefaultStateMachineExecutor实例,该实例在数据结构中维护延迟列表' ConcurrentLinkedList'在其内部。每次在AbstractStateMachine类的状态机的onInit()方法中将此执行程序实例化为新的执行程序。因此,我相信每当从工厂创建新实例并且机器对象使用先前的持久化上下文重新生成时,我们就会丢失停留在执行程序" deferredList"中的延迟事件。 。因为OOB持久性/恢复不会持久/恢复执行程序的状态,因此该执行程序上存在的延迟列表将丢失。 因此,在我们的情况下,当机器进入正确的状态,即WRITECHUNK时,执行程序已经丢失了在过去的事件调用中停留的延迟事件。因此,它们现在不能被机器自动触发,因为暂停事件现在不存在于执行器中。

** 2. **在Spring文档中给出的简单状态机示例中,我尝试配置延迟事件并且它正常工作,并且在达到有效状态后,停放的事件自动被触发。在这些示例中,状态机从第一个事件到最后一个事件从那时起不断启动和运行。因此,同一个DefaultStateMachineExecutor实例的机器的相同实例对象直到最终工作。

3.Maven依赖lib版本如下:

a.spring-statemachine-core:2.0.0 b.spring-statemachine-uml:2.0.0

申请解决方案?

当看到我们持久保存上下文并在每次收到的REST调用上恢复它时,是否需要进行任何设计更改或处理DefaultStateMachineExecutor的这种情况?或者我很想理解上面提到的有关上述结论的一些事情,我在排除故障时已经到了

提前感谢您。

1 个答案:

答案 0 :(得分:0)

是的,这需要对机器本身进行一些更改。这是一个有点复杂的问题,一般来说,我们需要通过持久性来检查其他与事件相关的事情。这些是在gh-550

中跟踪的