时间戳

首页 > 解决方案 > 如何使用“solace-jms-spring-boot”API 连接到多个 VPN

spring-boot - 如何使用“solace-jms-spring-boot”API 连接到多个 VPN

问题描述

我成功地实现了 Spring-boot 应用程序以连接到单个 VPN，并使用此处提供的说明（非常有帮助）在该 VPN 上的队列中消费/产生消息： https ://github.com/SolaceProducts/solace- jms-spring-boot

但现在我正在努力解决以下问题：根据我的阅读，使用此属性我们只能指定一个 VPN：solace.jms.msgVpn

如何连接到 2 个不同的 VPN 并从每个 VPN 中的队列消费/生产？我们可以在同一个 Spring Boot 应用程序中执行此操作吗？

任何帮助都感激不尽。

另一个问题 - 我们如何使用这些 API 确认返回的消息？

标签： spring-bootjmssolace

解决方案

虽然您目前无法solace-jms-spring-boot一次连接多个 VPN，但您有两种选择：

  1. 在不同的主题上发布回同一个 VPN，并使用 VPN 桥将其桥接到另一个 VPN。这种方法的优点是，如果需要，您可以桥接到许多其他 VPN，这些 VPN 可以位于同一个或另一个代理上。由于这是在管理上完成的，因此除了发布到新主题外，不需要对应用程序进行任何更改。请注意，您需要配置网桥和订阅，这需要管理访问权限。如果您使用新的动态消息路由功能，您可以减少或消除与配置主题相关的管理负担。DMR 跨多个站点工作，并在添加或删除订阅时动态处理消息路由。

  2. 在您的 Spring Boot 应用程序中使用 Solace Spring Cloud Stream (SCS) binder（可在 GitHub 和 Maven Central 上获得）。binder 支持在同一个应用程序中使用相同或不同传输的多个 binder - 在这种情况下，您可以将两个 Solace binder 定义到同一个 broker 但具有不同的 VPN 名称。

关于确认消息，solace-jms-spring-boot您不需要显式确认消息，因为 Spring JMS 使用本地事务。如果您的回调引发异常，则事务将回滚，否则将提交。如果它被回滚，默认情况下消息将返回队列并重新传递。这可能会导致您的应用程序进入无限循环尝试处理错误消息，因此建议max-redelivery在队列上设置属性 > 0，并指定一个死消息队列，在超过重新传递限制后毒消息将进入该队列。默认情况下，DMQ 是#DEAD_MSG_QUEUE，您可能需要创建它。请注意，消息还必须在 DMQ 合格标志设置为 true 的情况下发布。

如果您决定改用 SCS 绑定器，则确认机制会有所不同，并且不使用本地事务，而是由 SCS 管理。有关重试、DMQ（也称为 DLQ）以及全局和应用程序级错误处理程序的详细信息，请参阅 SCS 参考文档。由于 SCS 提供了类似的功能，您不需要在代理上配置 max-redelivery 或 DMQ，并且消息不需要设置 DMQ 合格标志。相反，您需要在应用程序属性/YAML 中配置错误处理。一般来说，当你的应用抛出异常时，会尝试重新投递，超过投递限制（默认为 3 次）后，要么进入 DLQ，要么进入应用或全局级别定义的错误处理程序。如前所述，这将取决于您的配置。

此处是禁用本地事务的示例。然后，您可以使用setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE)来启用客户端确认。但是，任何异常都不能回滚其他操作（例如，如果您在另一个会话上发布回复）。请注意，您的@JmsListener注释应指定containerFactory引用您的容器工厂的参数。

根据文档指出，DefaultMessageListenerContainer如果您想避免消息丢失或非原子操作，最好使用事务。当您的回调成功返回时，事务和客户端确认均已完成。

推荐阅读