WebSphere MQ Low Latency Messaging - JMS (または JMS のような) API はありますか?

Question

現在、JMS 経由で IBM MQ を使用していますが、処理できる量を超えるメッセージが送信されているようです。奇妙なことに、問題は断続的に発生しているようです。

メッセージは価格であるため、保証する必要はなく、すぐに送信する必要があります。

IBM には 低遅延製品, 、それがおそらくより良い解決策であるかどうか疑問に思っていますが、JMS API がないようです、または少なくとも簡単に表示されないようです。

Low Latency 製品に JMS API が含まれているかどうか、あるいはその「独自の」API が JMS に似ているのかどうかは誰でも知っています...

あるいは、MQ チューニングの指針もいただければ幸いです...:)

Answer 1

あなたの問題には、間違いなく低遅延メッセージング製品の方が適しています。私は、LBM と呼ばれる低遅延メッセージング製品を使用して、非常に似たようなことを行うプロジェクトに取り組んでいます。 29西. 。これには JMS API がありませんし、低レイテンシー分野のほとんどの製品には JMS API がないのではないかと思います。この種の製品と組み合わせると意味をなさない機能が多数あります (例:永続性、セレクターなど)。メッセージング製品の上に独自の単純な API を記述するのは非常に簡単で、後で製品を変更する柔軟性が得られ、JMS API の大量で冗長な部分から解放されることがわかりました。

考慮すべき別のオプションは次のとおりです Jグループ.

29West は、メッセージング製品ラインに JMS サポートを追加しました。

Answer 2

「MQチューニングのポイント」については、 サポートパックページ プラットフォームごとのパフォーマンス評価と具体的な推奨事項があります。MP* という名前の SupportPac まで下にスクロールし、適切なバージョンとプラットフォームを探します。大小のメッセージ、永続的なメッセージと非永続的なメッセージ、ゲッターとパターの数の変化などを使用して、さまざまなシナリオがテストされます。

Answer 3

LLM 製品の元開発者として、私はそれが実際に行われているか、少なくとも行われたと言えます。バージョン 2.6 の一般公開されている情報センターからの抜粋については、以下を参照してください。

そうは言っても、私の記憶によれば、MQ の要点は次のとおりでした。 保証された配達. 。これには時間と場所がありますが、遅延と帯域幅の点でコストがかかります。

LLM には根本的に異なる目的があります。それは持っています 確実な配送:つまり、配信に失敗した場合は、単に配信に失敗したことがわかります。これらのメッセージの回復可能性は、どれだけキャッシュしておくか、またはディスクから呼び出すか、つまり、プロセスを停止している間にどれだけの時間回復を待つことに耐えられるかによってのみ制限されます。あなたの場合、回復する気はないかもしれません。LLM があなたに適しているかどうかは推測できません。私が言えるのは、過去の開発者として、そしてその後クライアントとしての私の観点からすると、両者の間に類似点はほとんど、あるいはまったく見つからず、この種のアプリケーションにおける LLM のパフォーマンスは MQ を完全に吹き飛ばしたということです。また、私は Java/jms 側をあまり使用したことがなく、C/C++ に重点を置いていたので、これを一粒で理解してください。それができることと、グーグルでどこを調べればよいかだけは知っていました。

http://www-01.ibm.com/support/knowledgecenter/SSQPD3_2.6.0/com.ibm.wllm.doc/api/javadoc/messaging/com/ibm/llm/jms/package-summary.html

パッケージ com.ibm.llm.jms の説明

LLM JMS クライアントのプロバイダー固有のパブリック クラスを実装します。

JMSで使用されるインターフェイスのほとんどは、一般的なJMSインターフェイスによって定義されます。ただし、JMS仕様には、JMSクライアントを構成するために必要なクラスとインターフェイスは含まれていません。

JMSクラスとメソッドに関する情報については、JMS APIドキュメントを参照してください。

導入

LLM JMSクライアントは、LLMにJavaメッセージサービス（JMS）インターフェイスを提供します。JMSインターフェイスをLLMに使用すると、他のメッセージングプロバイダーとの共通インターフェイスが可能になり、開発者がよく知っているインターフェイスを使用できるようにすることでアプリケーション開発を速めます。JMSインターフェイスを使用すると、設定を中央に管理できる一般的なメッセージング関数を使用するアプリケーションに最適です。これには、多くの従来のクライアント アプリケーションが含まれます。LLM JMSクライアントは、アプリケーションがLLM固有の関数に依存している場合、またはLLMとの重要なアプリケーションの相互作用が必要な場合、うまく機能しません。JMSインターフェイスを使用してレイテンシーが追加されていますが、非常に低いレイテンシと高スループットメッセージングを提供します。

LLM JMSクライアントは、ほとんどのLLMクライアント機能をサポートしていますが、ティア内で実行されるサーバー関数、またはロードバランストランスミッターであることをサポートしていません。

LLM は、生産者から消費者への直接メッセージングを行うことに基づいています。JMSは通常、メッセージサーバーとJMS関数を使用して実装されます。これは、LLM JMSクライアントを使用するときにメッセージサーバーを使用できないことを必要とします。これには、すべてのポイントツーポイントメッセージング（キュー）および回復関数が含まれます。LLM JMSクライアントは、JSE環境で実行されるように設計されており、アプリケーションサーバー拡張機能またはXAトランザクションをサポートしていません。

LLM JMS クライアントが JMS を実装する方法

LLM JMSクライアントは、外部から露出していない実装クラスを使用して、基本的なJMSオブジェクトのそれぞれを実装しています。これらのオブジェクトのサブクラスは、同じ実装クラスを使用して実装されます。これは、ConnectionFactoryと宛先の管理されたオブジェクトが2つしかないことを意味します。LLM定義されたConnectionFactoryは、TopicConnectionFactoryおよびQueeConnectionFactoryにキャストでき、LLM定義の宛先はトピックとキューにキャストできます。同じことが、接続、セッション、メッセージプロデューサー、MessageConsumerにも当てはまります。1つのプロバイダーからの宛先オブジェクトは、同じプロバイダーによる接続で使用する必要があります。ただし、あるJMSプロバイダーが作成したメッセージを別のJMSプロバイダーに送信することは可能です。別のJMSプロバイダーによって作成されたメッセージの送信は、LLM JMSクライアントが作成したメッセージを送信するほど効率的ではありませんが、この関数は、アプリケーションがあるプロバイダーから別のプロバイダーに簡単にブリッジできるようにするために提供されます。

LLM JMSクライアントは、ポイントツーポイントメッセージングモデル（キュー）を実装していませんが、すべてのJMSオブジェクトを作成できます。

LLM JMS クライアントには、少なくとも Java 5 の JVM が必要です。

LLM JMSクライアントは、6つのメッセージタイプオブジェクトすべて（メッセージ、Bytesmessage、MapMessage、ObjectMessage、StreamMessage、TextMessage）すべてを定義します。JMSからJMSにメッセージを送信するとき、JMSヘッダーはメッセージのタイプを示します。JMSヘッダーが欠落している場合（JMS以外のプロデューサーからメッセージを送信するときに一般的です）、LLM JMSクライアントは、コンテンツからのメッセージのタイプを推定しようとします。通常、メッセージはバイトメッセージとして表示されますが、メッセージがUTF-8 BOMで始まるか、XMLのように見える場合、テキストメッセージとして解釈されます。TextMessage は UTF-8 でコーディングされていると想定されます。