server1 と server2 の 2 つのサーバーがあります。両方のサーバーは、Wildfly 11 のドメイン モード構成で実行されています。両方のサーバーの構成方法に関するドキュメントは次のとおりです。
この場合、server1 ドメイン ノードを考えてみましょう。
問題：
同じグループ ID を持つ 2 つのメッセージがサーバー 1 とサーバー 2 に同時に到着した場合、どちらのコンシューマーにメッセージを送信すればよいかわかりません。したがって、メッセージは異なるコンシューマーによって処理されることになり、最初に到着したメッセージが後で処理されることがありますが、これは望ましくありません。どちらのコンシューマーがメッセージを処理する必要があるかを両方のノードが認識できるように、システムを構成したいと考えています。
私たちが試した解決策：
グループ ハンドラー LOCAL を使用して server1 を構成し、REMOTE を使用して server2 を構成しました。これで、メッセージが到着するたびに、LOCAL グループ ハンドラーは、その特定のグループ ID のコンシューマーがどのノード上にあるかを識別し、それに応じてメッセージが選択されます。
このソリューションは、server1 が正常に動作するまで有効です。ただし、server1 がダウンすると、メッセージは処理されません。これを修正するために、server1 のメッセージング サブシステム active-mq のバックアップを server2 に追加し、同様に server2 にも同じことを行いました。
/profile=abc/subsystem=messaging-activemq/server=backup:add
(server1 がドメイン ノードであるため、バックアップ サーバーは両方のノードに追加されます)
また、同じ検出グループ、http コネクタ、ブロードキャスト グループをこのバックアップ サーバーに追加しました。バックアップ サーバーとライブ サーバーのクラスター接続を確立して、サーバー 1 とサーバー 2 の同じグループに配置しました。
/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 グループ ハンドラーを使用するサーバーがシャットダウンするシナリオをどのように構成できるかを提案してください。