简体繁体 English

如何检查spring-integration SI流中的任何通道是否处于加工状态？

[英]How to check that any of the channel in spring-integration SI flow is in processing state?

原文 2016-05-04 18:36:24 3 1 java/ spring/ spring-integration/ spring-integration-sftp

Hi Artem / Gary/ Friends, 您好Artem / Gary / Friends，

There is a requirement where I need to deploy my ear on application server on PROD. 我需要在PROD上的应用程序服务器上部署我的耳朵。 The solution flow starts with JMS Message Listener in SI flow and the whole framework is SI based, where we have used delayer aggregator JDBC outbound adapter. 解决方案流程从SI流程中的JMS消息侦听器开始，整个框架基于SI，我们使用了delayer聚合器JDBC出站适配器。 Now before deployment I need to know that there is no live thread active in SI flow ( means processing has been completed by all the channel and there is no live message in between ) so that I can begin the deployment of EAR on my application server. 在部署之前，我需要知道SI流中没有活动线程（意味着所有通道都已完成处理，中间没有实时消息），因此我可以在应用服务器上开始部署EAR。 As I have used control bus to stop the message listener but I also need to know that the message processing has been completed to end and no live SI message exists in the flow. 由于我已经使用控制总线来停止消息监听器，但我还需要知道消息处理已经完成以结束并且流中不存在实时SI消息。

Can you please help. 你能帮忙吗？

Thanks Ram 谢谢拉姆

1 个解决方案

Well, actually I'm not sure why you worry about that. 好吧，实际上我不确定你为什么担心这个。 Any re-deploy causes the application stop and resources disposal, therefore, no more any thread activity after that. 任何重新部署都会导致应用程序停止和资源处理，因此，之后不再有任何线程活动。

Although you can consider to use SmartLifecycleRoleController for the purpose like assign for all critical endpoints the same role and invoke its stopLifecyclesInRole() when you need. 虽然您可以考虑使用SmartLifecycleRoleController ，例如为所有关键端点分配相同的role并在需要时调用其stopLifecyclesInRole() 。

From other side the endpoint stop means that it won't consume any new messages from the channel (or source system like JMS). 从另一端来看，端点stop意味着它不会消耗来自channel （或像JMS这样的源系统）的任何新消息。 Right any long-running Thread will be still active and may be even with some process around the message. 任何长时间运行的线程都将保持活动状态，甚至可以对消息进行一些处理。 AFAIK the container tries to finalize all the active threads for the application and eventually just interrupts if otherwise. AFAIK容器尝试最终确定应用程序的所有活动线程，否则最终只会中断。 For this case you definitely should ensure some transactional / anknowlage rejection semantics for critical data. 对于这种情况，您肯定应该确保关键数据的某些事务/知识拒绝语义。 Therefore any unfinished process will just end up with rallback/nack state for the message. 因此，任何未完成的进程最终都会以消息的rallback / nack状态结束。 And a new instance of your application will be able to start over for that message again. 并且您的应用程序的新实例将能够再次重新开始该消息。

I don't have any answer for you regarding some hook to check thread activity at run time. 关于在运行时检查线程活动的一些钩子，我没有任何答案。 But I wonder if you will be able to figure out something like claim-check to wait until sending part is equal to processed after the JMS Inbound Endpoint stop. 但是我想知道你是否能够找出类似于claim-check东西，等到JMS入站端点停止后sending部件等于processed 。