【问题标题】:Spring Integration DSL JMS Request/Reply FlowSpring Integration DSL JMS 请求/回复流
【发布时间】:2014-12-11 22:28:57
【问题描述】:

我正在尝试使用这样描述的 Spring Integration Java DSL 创建请求/回复流:

IntegrationFlows.from(directChannel)
                .handle(Jms.outboundGateway(connectionFactory)
                        .requestDestination(requestDestination)
                        .replyDestination(replyDestination))
                .handle(replyHandler)
                .get();

如果我终止了应该处理回复的应用程序,那么回复会留在队列中,并且不会在应用程序下次启动时被使用。当我使用此流程发送后续请求时,收到的是上一条消息,而不是最新的回复。

我正在测试的消息流看起来像

App A 发送消息 -> 停止 A -> App B 接收消息并发送回复 R1

A 启动 -> A 发送另一个消息 -> B 接收消息并发送 回复 R2 -> A 收到 R1

R2 留在队列中

我做错了吗?

谢谢!

【问题讨论】:

    标签: spring-integration spring-jms


    【解决方案1】:

    这种情况根本不应该发生,我希望 R1 永远留在队列中,因为网关使用消息选择器来接收基于出站消息 ID 的回复。所以新实例不应该选择旧消息。

    在这种模式下,它希望接收应用程序将入站消息 id 复制到 JMSCorrelationID 标头。当入站消息没有JMSCorrelationID 时,这是一种常见的 JMS 模式。

    尝试将correlationKey 设置为JMSCorrelationID。在这种模式下,请求网关对每个实例使用唯一的 id,并且它希望接收方简单地回显入站 JMSCorrelationID 标头。

    如果你能得到双方的调试日志,它可能有助于追踪它。

    【讨论】:

    • 感谢您的回复。如果我希望使用这条旧消息,因为每条消息都很重要并且需要处理,那么我是否应该创建一个单独的集成流,其中包含一个通道来监听回复队列?
    • 在请求/回复场景中没有意义,因为请求者不再在那里接收响应。它会被送到哪里?如果您想要任意双向消息传递(而不是请求/回复),那么,是的,您应该使用通道适配器(出站和入站)。然后由您来进行关联。
    • 谢谢!现在说得通了。
    猜你喜欢
    • 2016-11-24
    • 2016-05-07
    • 2022-12-01
    • 1970-01-01
    • 1970-01-01
    • 2020-10-24
    • 2018-10-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多