JMSセレクタはキューの深さに応じてどのように拡張されますか？

キューからメッセージを消費するときにJMSセレクタを適用するアルゴリズムの時間的複雑度はどのくらいですかn？特に、読み取りごとに線形（O（n））ですか？それは実装依存（JMSプロバイダ上）であり、どのフィールドが要求されているかによって異なりますか？JMSセレクタはキューの深さに応じてどのように拡張されますか？

（実装に依存する場合、特にWebsphere MQとSolaceの動作に興味がありますが、特に複雑さを説明するドキュメントへのリンクがある場合は、特定のJMSプロバイダを扱う答えを歓迎します）。

動機：各メッセージには、invocationIDとbatchNameという2つのプロパティがあります。バッチはいくつかの呼び出しで構成されています。クライアントは2つの方法のいずれかでメッセージを消費することを望みます。 invocationIDまたはbatchNameのいずれかです。メッセージが生成される時点で、どのメソッドを使用するのか分かりません。

これは、セレクタを介して実装することができます。

invocationID=42

それとも

batchName="reconciliation"

を...と私は代わりに、カスタムプロパティの相関IDを使用して、これらのいずれかをスピードアップするが、午前ことができますもう一方は遅いと懸念しています。

出典

2012-11-19 bacar

大きな質問です！私はこれが良い答えを得ることは非常に難しいと思っていますが、明らかに特定の建築上の意思決定を行う上で基本的に重要です。 –

ありがとう@TomAnderson！ – bacar

According to the docsの順にメッセージが検索されます。しかし、WMQでは、MessageIDとCorrelIDフィールドのインデックスが作成されます。次のようにインフォメーション・センターは、動作を説明します。

は、キューからメッセージを選択がキュー上の各メッセージを検査順次のWebSphere MQが必要です。選択基準に一致するメッセージが見つかるまで、または件以上のメッセージが検査されるまで、メッセージは検査されます。したがって、深いキューでメッセージ選択を使用すると、メッセージングのパフォーマンスが低下します。

選択はのJMSCorrelationIDまたはJMSMessageIDを上に基づく場合形態のJMSCorrelationID = ...またはJMSMessageIDを= ...と参照だけつのプロパティの選択文字列を使用して、深いキュー上のメッセージの選択を最適化します。

この方法では、JMSCorrelationIDでを選択するとパフォーマンスが大幅に向上し、JMSMessageIDのパフォーマンスはわずかに改善されます（）。

マルチプレックスキューの要件についてもっと理解したいと思います。複雑なセレクタは誰の実装でもパフォーマンスに影響を与えます。より単純なセレクタで複数のオープンハンドルを使用する代わりに、複数のキューを使用するよりもアプリケーションコードと変わりません。もちろん、WMQの場合、動的キューまたは永久に定義された多くのキューはまったく問題ありません。非常に頻繁に私がこの要件を見ると、それはパフォーマンスが深刻な潜水艦を多く持つ定義された他の輸送手段を使用していた店舗から来ており、WMQでも同様であるという前提があります。他のケースでは、Pub/Subと永続的なサブスクリプションで要件が満たされています。私は、この要件の有効なケースがないことを示唆しているわけではなく、単にそれが何を駆動しているのだろうと思っています。

出典

2012-11-20 04:12:29

偉大な答え、リンクありがとう！セレクタ自体は複雑ではありません（おそらく1つのプロパティで平等になる） - 必ずしも必ずしも相関関係にあるとは限りません！（これはすでに使用されています）。 – bacar

セレクタは複雑ではありません。私はモチベーションの詳細を少し追加し、多少不正確であったため、多重化の言及を削除しました。 – bacar

説明をありがとう！それはPub/Sub問題のように聞こえる。管理サブスクリプションを使用してメッセージの1つのコピーをキューに置くことができ、クライアントはCorrelIDによってメッセージを取り出すことができます。他のプロパティに興味を持つクライアントは、単にトピックとしてサブスクライブすることができます。これらは動的または耐久性のあるサブスクリプションである可能性がありますが、選択がパブリケーション時に評価されるため、各クライアントは関心のあるメッセージのみを取得し、サブスクリプションキューFIFOを読み込むことができます。もちろん、実行時に選択が変更された場合、これは機能しません。 –

すべては実装によって異なります。多くのJMSプロバイダは、セレクタの実装にSQLを使用できるように、メッセージをSQLデータベースに格納します。この場合、特定のケースがどのようにSQLにマップされているかを調べる必要があります。

WebSphereMQの場合、セレクタの実装はJMSMessageID = sthとJMSCorrelationID = sthの場合O（log n）ですが、それ以外の特定の知識はありません。経験からは、O（n）のように見えます。

出典

2012-11-19 00:25:29 ShyJ

ありがとうございます。これらのフィールドのWMQの複雑さをどのように知っていますか？ドキュメンテーションへのリンクがありますか？これはプロファイリング/推測に基づいていますか？ – bacar

@bacar数十年前から、私はWMQを多用したプロジェクトに携わり、いくつかのパフォーマンステストを行いました。この分析は私が書いたように複雑さがあることを示しました。私はどのドキュメンテーションでそれを見つけていない。 – ShyJ

WebSphere MQバージョン7では、セレクタの実装が変更されました。 v7 JMSクライアントとv7 QueueManagerでは、選択処理はQueueManager側で実行されます。 v6 JMSクライアント（または実際には移行で動作するv7クライアント）モードでは、すべてのメッセージがクライアントに渡されて処理されます。一致するメッセージのヒット率が低い場合、無駄な努力が多かった。したがって

v7では処理がQueueManager側で行われるため、一致するメッセージのみがクライアントに送信されます。

QueueManagerは、データベースのようにメッセージプロパティの複雑なインデックスを保持しません。したがって、より単純なセレクタが優れています。

出典

2012-11-19 16:03:52 Calanais

ありがとうございます。すべての有用な情報ですが、v6またはv7を使用するかどうかにかかわらず、線形になる可能性があります。つまり、v7はクライアントではなくサーバー上で作業を行うことができます。（O（n））を使用して、セレクタに一致するものを見つける。 – bacar

JMSセレクタはキューの深さに応じてどのように拡張されますか？

答えて

関連する問題