是否可以使用 Wildfly 10 为 JMS-Bridge 配置故障转移到 JMS-Cluster？

Question

我有两个 JMS 服务器，它们在一个独立的全 ha 环境中作为一个 JMS 集群链接在一起。这些服务器托管我的 JMS-Destinations（我们称它们为 JMS-Master）。

另外还有一个服务器被配置为独立完整服务器（我们将其命名为 JMS-Slave）。这个服务器有一个 JMS-Bridge 到一个 JMS-Topic。

对于这个配置，我在 JMS-Slave 创建了两个到远程服务器的套接字绑定：

<outbound-socket-binding name="remote-server-1">
    <remote-destination host="a.b.c.d" port="8080"/>
</outbound-socket-binding>
<outbound-socket-binding name="remote-server-2">
    <remote-destination host="a.b.c.d" port="18080"/>
</outbound-socket-binding>

我在消息子系统配置的两个 http 连接器上使用它们：

<http-connector name="remote-1-http-connector" socket-binding="remote-server-1" endpoint="http-acceptor"/>
<http-connector name="remote-2-http-connector" socket-binding="remote-server-2" endpoint="http-acceptor"/>

我创建了一个池连接工厂：

<pooled-connection-factory name="remote-connection" entries="java:/jms/remoteCF" connectors="remote-1-http-connector remote-2-http-connector" user="testuser" password="testpassword" failover-on-initial-connection="true"/>

最后我配置了 JMS-Bridge：

<jms-bridge name="HelloWorldQueue-jms-bridge" quality-of-service="DUPLICATES_OK" failure-retry-interval="5000" max-retries="-1" max-batch-size="10" max-batch-time="100">
    <source connection-factory="ConnectionFactory" destination="queue/HelloWorldQueue"/>
    <target connection-factory="jms/RemoteConnectionFactory" destination="queue/HelloWorldQueue" user="heinz" password="becker" >
        <target-context>
            <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
            <property name="java.naming.provider.url" value="http-remoting://a.b.c.d:8080, http-remoting://a.b.c.d:18080"/>
        </target-context>
    </target>
</jms-bridge>

结果：

• 如果两个 JMS-Master 服务器都启动并且我启动了 JMS-Slave， 一切正常。
• 如果其中一台 JMS-Master 服务器出现故障并且我启动了 JMS-Slave，它 也可以。 jms-bridge 连接到可用节点。
• 但是如果我关闭了 JMS-Slave 的 JMS Bridge 所连接的节点 已连接，没有故障转移。

我正在寻找一种配置，其中 JMS-Bridge 在与可用节点崩溃后“重新连接”，而不是将其与 JMS-Master 进入同一个集群。

我怎样才能做到这一点？还有其他可能获得类似行为吗？或者是否有关于完全不同的设置的建议？

Answer 1

我想我自己找到了两种可能的解决方案。但它们都有一些缺点。

第一个是使用 JMS-Core-Bridge。见Configuring Core Bridges at the Red Hat JBoss docs：

不要将核心网桥与 JMS 网桥混淆。使用核心桥 桥接任何两个 JBoss EAP 消息传递实例并使用核心 API。 JMS 桥可用于桥接任何两个符合 JMS 1.1 的 JMS 提供者并使用 JMS API。最好使用核心桥 尽可能代替 JMS 桥。

Core-Bridge 或多或少地进行了开箱即用的故障转移。已经有了一个连接器，它会自动进行故障转移。它在第一次连接期间检索集群拓扑并在其生命周期内使用它。为了能够在 JMS-Master 宕机时启动桥接器，我们可以添加额外的连接器：

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
    <server name="default">
        ....
        <bridge name="my-core-bridge" static-connectors="remote-1-http-connector remote-2-http-connector" queue-name="jms.queue.HelloWorldQueue" user="username" password="pwd"/>
    </server>
    ...
 </subsystem>

核心桥的缺点似乎是它不支持开箱即用的 JMS-Topics。只有 JMS-Queues 似乎可以在没有开销的情况下工作。

但也可以配置一个重新连接到另一台服务器的 JMS-Bridge。为了建立连接，JMS-Bridge 在由属性 “java.naming.provider.url” 配置的服务器之一上进行 JNDI 查找。此查找仅在启动期间执行，完成后，它使用检索到的远程连接工厂（此处名为 RemoteConnectionFactory）进行连接和重新连接。但它使用的是 JMS-Master 的 RemoteConnectionFactory！因此有必要 在那里配置这个连接工厂：

<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="master-1-http-connector master-2-http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>

如果此 RemoteConnectionFactory 有一个连接到每个 JMS-Master 的连接器，JMS-Bridge 会检索所有必要的信息以重新连接到另一个服务器（如有必要）。我的问题的网桥配置现在无需修改即可工作：

<jms-bridge name="HelloWorldQueue-jms-bridge" quality-of-service="DUPLICATES_OK" failure-retry-interval="5000" max-retries="-1" max-batch-size="10" max-batch-time="100">
    <source connection-factory="ConnectionFactory" destination="queue/HelloWorldQueue"/>
    <target connection-factory="jms/RemoteConnectionFactory" destination="queue/HelloWorldQueue" user="username" password="pwd" >
        <target-context>
            <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
            <property name="java.naming.provider.url" value="http-remoting://a.b.c.d:8080, http-remoting://a.b.c.d:18080"/>
        </target-context>
    </target>
</jms-bridge>

我的“jms-bridge 配置”的缺点是它的复杂性。