8

ActiveMQ とそのコンシューマでランダムな問題に直面しています。ActiveMQ キューに接続されているにもかかわらず、ほとんどのコンシューマーがメッセージを受信して​​いないことがわかります。ただし、コンシューマーの再起動後は正常に機能します。

ActiveMQ 側に testQueue という名前のキューがあります。コンシューマーがこのキューからメッセージをデキューしようとしています。この目的のために、Spring の DefaultMessageListenerContainer を使用しています。メッセージは ActiveMQ Broker からコンシューマー ノードに配信されています。tcpdump からも、メッセージがコンシューマ ノードに到達していることは明らかでしたが、実際のコンシューマ コードはメッセージを確認できません。つまり、メッセージは ActiveMQ コンシューマ コードまたは Spring の DefaultMessageListenerContainer のいずれかにスタックしているようです。

下の図を参照してください。問題をより明確にするために。メッセージはコンシューマ ノードに到達していますが、「実際のコンシューマ クラス」には到達していません。これは、メッセージが AMQ コンシューマ コードまたは Spring DMLC でスタックしたことを意味します。

ここに画像の説明を入力

以下は、ActiveMQ 管理者からキャプチャされた詳細です。

Queue-Name /Pending-Message-Count /Consumer-Count /Messages-Enqueued /Messages-Dequeued testQueue /9 /1 /9 /0

以下、詳細です。

Connection-ID /SessionId /Selector /Enqueues /Dequeues /Dispatched /Dispatched-Queue /Prefetch ID:bearsvir52-45176-1375519181268-3:5 /1 / /9 /0 /9 /9 /250

2 番目の表から、メッセージがコンシューマに配信されていることは明らかですが、コンシューマはメッセージを確認していません。したがって、メッセージはブローカー側の Dispatched-Queue にスタックされます。

あなたの通知のためのいくつかのポイント:

1) ブローカーノードとコンシューマーノードの時間差はありません。

2) コンシューマー側で tcpdump を観察しました。MessageDispatch(Openwire) パケットがコンシューマー ノードに転送されていることがわかりますが、同じメッセージに対する MessageAck(Openwire) が見つかりませんでした。

3)ノードで動作している場合もあれば、同じノードで問題を引き起こしている場合もあります。

4

2 に答える 2

2

解決策を見つけるのに多くの時間がかかりました。AMQ フェイルオーバーの場合、 org.apache.activemq.ActiveMQConnection.javaクラスに問題があるようです。このような場合、接続オブジェクトはコンシューマー側で開始されません。

以下は、ActiveMQConnection.java ファイルに追加し、ソースをコンパイルしてactivemq-core-xxxjarを作成した修正です。

private final Object startMutex = new Object();

createSession メソッドにチェックを追加

public Session createSession(boolean transacted, int acknowledgeMode) throws JMSException {
    synchronized (startMutex) {
        if(!isStarted()) {
            start();
        }
    }
于 2015-02-28T03:55:47.270 に答える