我们有2台服务器：server1和server2。两台服务器均以Wildfly 11的域模式配置运行。这是the documentation，说明了我们如何配置两台服务器。

在我们的案例中，我们考虑server1域节点。

问题：

如果具有相同组ID的2条消息同时到达server1和server2，则它们将不知道该消息应发送给哪个使用者。因此，该消息最终由不同的使用者处理，并且有时先到达的消息随后被处理，这是不希望的。 我们希望对系统进行配置，以使两个节点都彼此知道该消息应由哪个使用者处理。

我们尝试的解决方案：

为服务器1配置组LOCAL，为服务器2配置REMOTE。现在，每当消息到达时，本地组处理程序就会标识该特定组ID的使用者位于哪个节点上，并相应地选择消息。

该解决方案在server1运行正常之前一直有效。但是，如果server1发生故障，则不会处理消息。为了解决此问题，我们将server1的消息传递子系统active-mq的备份添加到server2，并且类似地对server2进行了备份。

/profile=abc/subsystem=messaging-activemq/server=backup:add

（由于server1是域节点，备份服务器将被添加到两个节点）

我们还向该备份服务器添加了相同的发现组，http连接器，广播组。我们为备份服务器和活动服务器建立了群集连接，使其与server1和server2在同一组中。

/profile=abc/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=${livegroup},check-for-live-server=true)
/profile=abc/subsystem=messaging-activemq/server=backup/ha-policy=replication-slave:add(cluster-name=my-cluster,group-name=${backupgroup})

server1配置为读取以下属性：

livegroup=group1
backupgroup=group2

server2配置为读取以下属性：

livegroup=group2
backupgroup=group1

但是，当具有本地组处理程序节点的活动节点关闭时，此解决方案似乎无法解决故障转移条件，并且未在其他节点上处理消息。当server1关闭时，我们在server2上收到以下错误：

[org.apache.activemq.artemis.core.server] (default I/O-3) AMQ222092: Connection to the backup node failed,removing replication now: activeMQRemoteDisconnectexception[errorType=REMOTE_DISCONNECT message=null]
        at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:533)
        at org.apache.activemq.artemis.core.remoting.impl.netty.Nettyacceptor$Listener.connectionDestroyed(Nettyacceptor.java:682)
        at org.apache.activemq.artemis.core.remoting.impl.netty.activeMQChannelHandler.channelInactive(activeMQChannelHandler.java:79)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:360)
        at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:325)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1329)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
        at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:908)
        at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:744)
        at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)

请建议使用其他任何方法来解决该问题，或者如何配置带有LOCAL组处理程序的服务器关闭的方案。