0

ActiveMQ に基づくアプリケーション インフラストラクチャを構築しました。

メッセージを問題なく送受信でき、ほとんどの場合、かなり高速で問題ありません。

ただし、メッセージのバッチを「一度に」送信すると、たとえば 5,000 件のメッセージを送信すると、ActiveMQ は相手側のサードパーティ アプリケーションにメッセージを非常に迅速に取得し、このアプリケーションも非常に迅速に処理することに気付きました。 、また、応答をブローカにすばやく (たとえば 1 分以内に) キューに入れます。

しかし、何らかの理由で、最初にメッセージを発信した VB.NET EXE は、受信した返信メッセージを不規則に処理しているように見えます。毎秒 1 つ。

Origin (VB.NET EXE which we manage) 
    -> Broker  (which we manage)
        -> (3rd party app) 
            -> back to the same broker 
                -> back to the origin app.

レシーバーは、おそらく 9 か月前に ActiveMQ からダウンロードされた C# コードからのイベント MessageListener を待っています。

Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
     Member of: NMS

何が起きているかというと、MessageListener は 1 つのメッセージ (NMS.IMessage) しか提供しないので、それを処理します。

「MessageListener イベントで、現在キューに他のメッセージがあるかどうかを確認し、すべて実行してください」と言う方法はありますか?

4

2 に答える 2

1

結局のところ、これが何であるかについてはもう少しわかっていると思います。

ActiveMQDLLを使用するVB.NETWinFormsアプリが最終的にクラッシュすると（週に数回発生する傾向があります）、Winternals pslistおよびpskillユーティリティを使用してゾンビを刈り取り、新しいクライアントを起動するウォッチドッグプログラムがあります。繋がり。

これが発生した場合、jconsoleを使用してブローカーを分析すると、ゾンビのセッションがまだ登録されていることがわかり、新しいクライアントも登録されています。

私の現在の理論では、AMQは両方のセッションを検出すると、ラウンドロビン方式で両方のセッションへのメッセージの配信を開始しようとします。AMQは、応答しないゾンビにメッセージを送信しようとします。一定の時間（おそらく1秒）が経過すると、AMQはあきらめて、リスト内の次のセッションである新しい新しいクライアントに進みます。

ある時点で、ブローカーまたはTCPスタックは、ゾンビがTCP接続をアクティブに保っていないことに気づき、あきらめます。その後、動作は通常に戻ります。

したがって、問題は、a）死なない、またはb）正常に死んで、プロセス中のセッションをシャットダウンするActiveMQクライアントをどのように作成するかということです。

編集：ActiveMQの次のバージョンにアップグレードすると、これが解決されました。また、送信と受信を行う単一のアプリがありましたが、スレッドセーフではありませんでした。そのため、送信しようとしたときに受信した場合、クラッシュが発生しました。データを送信するコンソールアプリとデータを受信するコンソールアプリの2つのコンソールアプリとして書き直しました。これ以上のクラッシュはありません。また、当時使用していた古いバージョンのActiveMQはクラッシュを適切に処理しませんでしたが、4.xにアップグレードすると問題が解決しました。

于 2009-01-09T20:44:09.810 に答える
0

これをユーザー フォーラムに報告し、サポートの問題を提起することをお勧めします。これは、NMS クライアント コードの問題である可能性があり、すべての NMS 開発者がそのリストに含まれており、対応する可能性があるためです。

于 2008-12-31T07:44:55.163 に答える