問題タブ [qpid]

Apache Qpid の負荷/フェイルオーバー テストを行うためのテスト クライアントを構築しています。

管理者の担当者から、メッセージ ペイロードのバイトをランダム化する必要があると言われました。これについての彼らの理由は、テストの有効性に影響を与える可能性のある何らかのタイプのキャッシングが行われているということです。

すべてのペイロード バイトをランダム化するというすべての問題に取り組む前に (それ自体がテスト結果に影響を与えます)、これは本当ですか? 注意すべきインターフェイス レベルで発生するキャッシュはありますか? テスト結果に大きな影響を与える可能性があると思いますか? メッセージのペイロード以外に、変更される他のフィールドがあることを考慮してください (メッセージ ID、宛先、メタデータなど)。

私はオープン ソースのメッセージング ソフトウェアを探していて、かなりの調査を行った結果、これら 3 つの製品に出会いました。私はこれらの製品を予備テスト用に取り出し、キューとトピックのメッセージを処理してもらいました。私が読んだ限りでは、これら 3 つの製品はすべて、ほとんどの企業にとってオープン ソースのメッセージング ソリューションとして適しています。私が疑問に思っていたのは、これらの製品が互いにどのような利点を持っているのでしょうか? 私が特に関心を持っているのは、永続的なメッセージング スループット、セキュリティ、スケーラビリティ、信頼性、サポート、ルーティング機能、メトリックや監視などの管理オプション、および一般的に各プログラムが大規模なビジネス環境でどれだけうまく動作するかなど、メッセージング スループットです。

次のようなメッセージを送信する C++ パブリッシャーがあります。

そして、私は次のようなJavaサブスクライバーを持っています:

上記のコードでメッセージは受信されませんでした。これがどのように機能するのか非常に混乱していますか？消費者にとって正しい形式の bingding URL は何ですか? 私は何が欠けていますか？

春の構成

MyService.java

QPID を再起動すると

reconnectOnException=true がないと、この例外が発生し続けますが、再接続はしません

reconnectOnException=true を使用すると、接続および切断されます

apache qpid javaクライアントでrabbitmq-serverを使用する必要があります（apache camelを使用する必要があるため）。しかし、特にそれぞれがサポートしているamqpプロトコルのために、両方のバージョンと混同しています。

例として、rabbitmq-serverの最後の安定したリリースのために消費/生成できるJavaクライアントqpidのバージョンはどれですか？または可能な限り最高のペアバージョンは何ですか？qpid url形式で？

前もって感謝します。

クライアントがキューのみを参照できるように、Red Hat MRG /ApacheQPIDでのみキューを参照するように強制するにはどうすればよいですか。一部のクライアントがキュー外のメッセージを消費しようとしても、それを実行できないはずです。

corosyncOS Debianを使用しています。qpidd プログラムを開始したら、次のメッセージを書き込みます。

ClusterClock タスクに平均 70ms 遅れて 1 回警告する

メッセージ確認応答を確実にする方法は、jmsブローカーで確認応答が呼び出されたメッセージまでのメッセージのみを削除します。現在、jmsキューから消費し、部分的に処理するシステムがあります。しばらくすると、これらのメッセージのバッチが別のスレッドによって永続化されます。今メッセージを確認する必要があります。しかし、問題は、メッセージの消費を停止する必要があることです。そうしないと、以前に受信したメッセージを確認すると、後続のすべてのメッセージも確認されます。

つまり、キューに10個のメッセージがあるとします。私はそれらのうちの7つを消費し、次に5番目のメッセージで確認します。これにより、コンシューマーが受信した7つのメッセージすべてがキューから削除されます.5番目のメッセージまでメッセージを確認してキューから削除する方法はありますか？

編集：2つのセッションを作成し、異なるセッションから消費しようとしましたが、（少なくともapache qpidを使用して）これは一貫性のないパフォーマンスを示します。一貫性がないということは、テスト中に、どれだけ待っても、一方のコンシューマーがメッセージを受信でき、もう一方のコンシューマーがまったく受信しない場合があるということです。これは私にとっては解決策としてはうまくいきましたが、一貫性がないため、これを解決策として使用することはできません。

私は自分の会社のためにメール送信者のWebサービスを書いています。主な要件の1つは配信の保証であるため、永続的なQPidキューを使用して、JMSトランスポート上に薄いHTTPレイヤーがあります。

私が直面している問題の1つは、処理中のエラーの処理です。エラーが発生したときに単にトランザクションをロールバックすると、メッセージはキューの先頭に移動します。エラーが十分に蔓延している場合、誰かが手動で介入するまでキュー全体がロックされる可能性があります。その間にメッセージを処理できるように、ヘッドにポストバックすることでこれを回避したいと思います。

しかし、そこに私の問題があります。まず、AMQPにはメッセージを確認する代わりにアトミックに「拒否して再キューイング」するメカニズムがありますが、JMSにはこの機能の類似物がないようです。そのため、メッセージにアクセスする唯一の方法はキャストすることです。特定のJMS実装。さらに、CXFのJMSトランスポートには、トランスポートレベルで動作をオーバーライドまたは挿入する手段がないようです。つまり、バイトコードエージェントを作成するか、コードを変更して、必要な動作を取得するためだけに再コンパイルする必要があります。

この問題を回避するために、CXFメッセージからJMSメッセージを再構築し、それを再キューイングするだけのフォールトハンドラーをCXFに実装するというアイデアを試しました。しかし、障害が原因でオーバーライドできないロールバックが発生するため、トランザクションセッションを使用できません。その後、メッセージのコピーがヘッド（ロールバックから）とテール（ロールバックから）に表示されます。再キューから）。また、CLIENT_ACKNOWLEDGEを使用することはできません。これは、JMSトランスポートがメッセージを処理のために送信する前に確認応答するためです。つまり、サーバーが間違ったタイミングでダウンした場合、メッセージが失われる可能性があります。

したがって、基本的に、JMSトランスポートのデフォルトの動作を受け入れ続ける限り、データの整合性を損なうことなく、必要な動作（失敗したメッセージの再キューイング）を取得することは不可能のようです。

同僚は、JMSトランスポートを完全に避け、キューを直接呼び出すことを提案しました。その場合、サービスの実装は、メッセージをキューに入れるためだけに存在するスケルトンクラスになり、別のプロセスがメッセージリスナーを実装します。私にとって、このソリューションは、不可知論者のWebサービスの優雅さを失い、実装を基盤となるテクノロジーに結合することによってある程度のスケーラビリティを失うため、最適ではありません。

また、RabbitMQクライアントライブラリを使用してAMQP用のCXFトランスポートを作成することも検討しました。時間がかかりますが、これからも当社が使い続けられるものであり、CXFプロジェクトに貢献できるものかもしれません。とは言うものの、コードの記述、実行、テストに時間がかかるため、私はこのアイデアに夢中ではありません。

これがCXF用のbeans.xmlです。

私が見逃している単純なものはありますか？それとも、問題を回避するためのより良い方法はありますか？