現在、JMS経由でIBM MQを使用していますが、処理できる以上のメッセージを送信しようとしているようです。不思議なことに、この問題は断続的です。WebSphere MQ低遅延メッセージング - JMS（またはJMSのような）APIを備えていますか？
メッセージは価格であるため、保証する必要はなく、すぐに送信する必要があります。
IBMがLow Latency productを持っているので、おそらくそれがより良い解決策であるかどうか疑問に思っていますが、JMS APIがないと思われます。
JMS APIは、低遅延の製品に存在する場合誰もが知っている、またはそれが持っている「ユニーク」APIは、JMS-ようであれば...
はまた、MQのチューニングのためのポインタもいただければ幸いです。 .. :)
間違いなく、待ち時間の短いメッセージング製品が問題に適していると私は29WestというLBMという低遅延のメッセージング製品を使用して、非常に似通ったプロジェクトを進めています。 JMS APIはありません。待ち時間の少ない領域ではほとんどの製品がそうではないと思われます。これらのタイプの製品（例えば、永続性、セレクタなど）と組み合わせて意味をなさない多数の機能があります。私たちは、メッセージング製品のトップに独自の単純なAPIを書くことが非常に簡単であり、後で製品を変更する柔軟性を利用し、JMS APIの大部分と冗長性から解放することを発見しました。
もう1つの選択肢はJGroupsです。
29Westは、メッセージング製品ラインにJMSサポートを追加しました。
「MQチューニングのためのポインタ」に関しては、SupportPacs pageにはプラットフォームごとのパフォーマンス評価があり、特定の推奨事項があります。 MP *という名前のSupportPacまでスクロールし、適切なバージョンとプラットフォームを探します。大小のメッセージ、永続的および非永続的なゲッターやパターの数などのさまざまなシナリオがテストされます。
LLM製品の以前の開発者として、 。つまり、公開されているバージョン2.6の情報センターから抜粋した部分を参照してください。
これは、MQ全体のポイントがであることを思い出しています。これには時間と場所がありますが、レイテンシと帯域幅の面でコストがかかります。
LLMは根本的に異なる目的を持っています。 信頼できる配送：それが届かない場合、あなたは単にそれが届かなかったことを知っているでしょう。これらのメッセージの回復可能性は、ディスクからのキャッシュまたはリコールをどの程度保持しているかによって制限されます。したがって、プロセスを中断している間に回復を待つ時間はどれだけ長くなりますか。 LLMがあなたのために適切かどうか私は推測することはできません。私が言うことは、過去の開発者としての私の立場からは、後にクライアントとして、私は両者の間に似ていないことがほとんどなく、このようなアプリケーションのためのLLMのパフォーマンスはMQを完全に水から吹き飛ばしたということです。私はjava/jms側を使ったこともなく、C/C++に焦点を当てていましたので、これを塩の塊で取ってください。私はちょうどそれがそれをしたと知っていたとどこでGoogleを見て。
パッケージcom.ibm.llm。jms説明
LLM JMSクライアントのプロバイダ固有のパブリッククラスを実装します。
JMSで使用されるほとんどのインターフェイスは、共通のJMS インターフェイスで定義されています。ただし、JMS仕様には、JMSクライアントをコンフィグレーションするために必要なクラスとインタフェースの は含まれていません。
JMSクラス とメソッドの詳細については、JMS APIドキュメントを参照してください。
はじめ
LLM JMSクライアントは LLMへのJava Message Service（JMS）のインターフェースを提供します。 LLMへのJMSインターフェイスを使用すると、 の他のメッセージングプロバイダとの共通インターフェイスが可能になり、アプリケーション開発のスピードが になり、開発者は使い慣れたインターフェイスを使用できます。 を使用すると、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およびDestinationが2つしか管理されていないことを意味します。定義されたLLM ConnectionFactoryはTopicConnectionFactoryと QueueConnectionFactoryにキャストでき、LLMで定義された宛先は トピックとキューにキャストできます。 Connection、Session、 MessageProducer、MessageConsumerについても同様です。 1つの プロバイダーのDestinationオブジェクトは、同じプロバイダーがConnectionで使用する必要があります。ただし、 1つのJMSプロバイダによって生成されたメッセージを別のJMSプロバイダの に送信することは可能です。別のJMS プロバイダによって作成されたメッセージを送信することは、LLM JMSクライアントによって作成されたメッセージを送信するほど効率的ではありませんが、 アプリケーションが1つのプロバイダから別のプロバイダに容易に橋渡しできるようにするための機能です。
LLM JMSクライアントは、ポイントツーポイントメッセージング モデル（キュー）を実装していませんが、すべてのJMSオブジェクトを作成できます。
LLM JMSクライアントは、JVMが必要少なくともジャワ5
LLM JMSクライアントは、すべての6つのメッセージタイプのオブジェクト（メッセージ、 BytesMessageは、MapMessageの、のObjectMessage、StreamMessageの、及び のTextMessage）を定義します。 JMSからJMSへメッセージを送信する場合、JMSヘッダー はメッセージのタイプを示します。 JMSヘッダーがない場合（JMS以外のプロデューサからメッセージを送信する場合には が共通）、LLM JMS クライアントはコンテンツからメッセージのタイプを推定しようとします。 通常、メッセージはBytesMessageとして表示されますが、メッセージ がUTF-8 BOMで始まる場合、またはXMLのように見える場合は、 とTextMessageとして解釈されます。 TextMessagesはUTF-8でコード化されていると想定されています......
ありがとうございます - 私たちは一般的に過剰なボリュームや厳しい待ち時間の要件はなく、私たちの以前のソリューションであるFioranoもうまくいきました。残念ながら、会社の標準ではIBM MQを指示しています。 –