問題タブ [jms]

JMS API を使用して、メッセージを Websphere MQ サーバーに送信しています。私が作成したメッセージを取得するアプリケーションでは、MQMD 構造体の ApplicationID フィールドを定数値に設定する必要があります。JMS API で MQMD 構造にアクセスする方法が見つかりませんでした

質問: これを行う方法はありますか? はいの場合、どのように？いいえの場合、私の唯一のオプションは、JMS API の代わりに MQ Java API を使用することですか?

非同期リクエストに Apache Camel を使用するのは理にかなっていますか? または、JMS サーバーを使用して単純な MoM を使用する必要があります。必要なエンタープライズ統合パターンはありません。

どんな助けでも役に立ちます。

クライアントの1つは、注文単位のWeblogicサーバー機能（UOO）を使用することを目的としています。

カスタムUOO名を使用してJMSメッセージを送信するための純粋なJavaコードでUOOを使用すること、およびAqualogic Service BusでプロキシサービスからビジネスサービスにUOO名を伝播すること（両方とも転送プロトコルとしてJMSを使用）にすべてがOKです。

ただし、WeblogicIntegrationでWLIJMSControlとともにUOOを使用すると、正しく機能しません。

このコードを考えてみましょう：

MyCustomPropertyプロパティをJMSコンシューマーに送信しますが、プロパティJMS_BEA_UnitOfOrder（UOO名に関連）は無視されます。代わりに、デフォルトのユーザー生成UOO名が使用されます。

では、Weblogic JMSControlを使用してUOO名をカスタマイズするにはどうすればよいですか？

JBoss Messaging (JMS) を多用するプロジェクトに取り組んでいます。私は、他の開発者向けに Messaging の使いやすいラッパーを構築する任務を負っており、JMS のメッセージ セレクターを使用してフィルタリング技術を提供し、不要なメッセージの送信を最小限に抑えることを考えています。パフォーマンスに関して誰かが経験を持っているかどうか知りたいですか? 私が恐れているのは、JMS プロバイダーがメッセージ セレクターで行き詰まり、目的全体を事実上無効にしてしまうのではないかということです。ただし、メッセージの種類ごとにトピック/キューの長いリストを作成するよりもはるかに優れています。

最終的には、間違いなくこの 2 つの組み合わせを使用することになりますが、どちらに傾倒しても、パフォーマンスへの影響が懸念されます。

WLサーバーで以下のような警告がランダムに表示されます。これらの警告が正確に何であるか、そしてそれらを回避するために何をすべきかをよりよく理解したいと思います。

86,606秒後にトランザクションを破棄：Xid = BEA1-52CE4A8A9B5CD2587CA9（14534444）、Status = Committing、numRepliesOwedMe = 0、numRepliesOwedOthers = 0、beginからの秒数= 86605、残り秒数= 0、XAServerResourceInfo [JMS_goJDBCStore] =（ServerResourceInfo [J state = commitd、assigned = go_server）、xar = JMS_goJDBCStore、re-Registered = true）、XAServerResourceInfo [weblogic.jdbc.wrapper.JTSXAResourceImpl] =（ServerResourceInfo [weblogic.jdbc.wrapper.JTSXAResourceImpl] =（state = new、assigned = none）、xar = weblogic.jdbc.wrapper.JTSXAResourceImpl@1a8fb80,re-Registered = true）、SCInfo [go + go_server] =（state = commitd）、properties =（{weblogic.jdbc = t3：//10.6.202.37 ：18080}）、ローカルプロパティ=（{weblogic.transaction.recoveredTransaction = true}）、OwnerTransactionManager = ServerTM [ServerCoordinatorDescriptor =（CoordinatorURL = go_server + 10.6.202.37：18080 + go + t3 +、XAResources = {JMS_goJDBCStore、weblogic.jdbc.wrapper.JTSXAResourceImpl}、NonXAResources = {}）]、CoordinatorURL = go_server + 10.6.202.37：18080 + go + t3 +）

私はBEAの説明を理解しています：

エラー：秒秒後にトランザクションを放棄します：tx

説明：トランザクションが破棄されると、トランザクションの知識は、トランザクションを完了に追いやろうとしていたトランザクションマネージャーから削除されます。JTA構成属性AbandonTimeoutSecondsは、トランザクションマネージャーがトランザクションのコミットまたはロールバックを試行する際に存続する期間を決定します。

原因：AbandonTimeoutSeconds期間中、リソースまたは参加サーバーが使用できなかった可能性があります。

アクション：参加しているリソースでヒューリスティックな完了を確認し、データの不整合を修正してください。

* .tlogファイルを削除することでこれらの警告を取り除くことができることを確認しましたが、これは警告に対処するための適切な戦略ではないようです。

警告は、JMSとJMSストアに関するものです。私たちはJMSを使用しています。なぜトランザクションがぶらぶらしているのか、なぜ「放棄」されるのかがわかりません。

次のエラーが表示されます。

javax.jms.ResourceAllocationException: [C4073]: A JMS destination limit was reached. Too many Subscribers/Receivers for Queue

セットアップは、1 つのプロバイダーと 2 つのコンシューマーが存在するように行われました。このエラーが発生する理由は、それがキューであり、1 つのプロバイダーと 1 つのコンシューマーしか持てないためですか?

メッセージリスナーを一時的に無効にするための優れた方法は何でしょうか。私が解決したい問題は次のとおりです。

• JMSメッセージがメッセージリスナーによって受信されます
• メッセージを処理しようとするとエラーが発生します。
• システムがメッセージを処理できるように再び準備ができるのを待ちます。
• システムの準備が整うまで、これ以上メッセージは必要ないので...
• ...メッセージリスナーを無効にしたい。
• 私のシステムは再び処理する準備ができています。
• 失敗したメッセージが処理され、JMSメッセージが確認応答されます。
• メッセージリスナーを再度有効にします。

現在、SunAppServerを使用しています。MessageConsumerでメッセージリスナーをnullに設定して無効にし、setMessageListener（myOldMessageListener）を使用して再度有効にしましたが、その後メッセージが表示されなくなりました。

Tomcat/BlazeDS/ActiveMQ スタックで切断が発生しています。BlazeDS StreamingAMFChannel はデフォルトの idle-timeout-minutes 0 で構成されていますが、約 30 分のアイドル時間後にタイムアウトするようです (ログを参照)。その間、クライアントはリクエストを行わず、ActiveMQ トピックからメッセージをプッシュすることもありません。

ActiveMQ と BlazeDS でデバッグ ロギングを有効にすると、BlazeDS がコンシューマを削除していることがわかります。残念ながら、切断メッセージの前にログ メッセージがないため、これが BlazeDS 内でいつ呼び出されたかを実際に追跡することはできません。

他の誰かがこれを経験したことがありますか、または誰かが解決策を提供できますか?

* ActiveMQ ログ *

* BlazeDS ログ *

私は金融業界向けのソリューションに取り組んできました。アプリケーションの主な機能は、大量の入力ファイルを読み込み、それらを消化し、永続ストアの状態を更新し、要求に応じて永続ストアから抽出を生成する機能です。かなり簡単です。

入力ファイルは、多数の繰り返しエントリを含む、業界標準形式の大きな (数百メガバイトを超える) XML メッセージです。永続ストレージはリレーショナル データベースです。エンジンは、J2EE アプリケーション サーバーにデプロイ可能な POJO ベース (バックボーンとしての Spring Framework) Java アプリケーションとして実装されています。

問題は、ソリューションのスケーラビリティとパフォーマンスに関するものです。アプリケーションが XML からのエントリを順番に処理する場合、ソリューションのスケーラビリティはやや劣ります。アプリケーションの複数のインスタンスを 1 つのファイルの処理に関与させる方法はありません。これが、入力 XML ファイルからのエントリの並列処理を導入した理由です。基本的には、ワーカーの個々のエントリの処理をプールからディスパッチするという考え方です。ディスパッチには JMS を使用することにしました。ファイルをロードするコンポーネントはストリームを読み取り、単純に単一のエントリを抽出してディスパッチ キューにフィードします。キューの反対側には多数のコンシューマーが同時にいます。それぞれがキューの 1 つのメッセージを選択してエントリを処理し、すぐに他のエントリを処理できるようになります。これは、Web コンテナー内のサーブレットとよく似ています。このアプローチで特に強力な点は、キューが共有されている限り、リモート サーバーにデプロイされたアプリケーションの個別のインスタンス内にワーカーを配置できることです。残念ながら、すべてのワーカーは永続ストレージを維持する同じデータベースに接続します。データベース サーバーが同時ワーカーからの負荷を処理するのに十分強力でない場合、これがボトルネックになる可能性があります。

このアーキテクチャについてどう思いますか? デザインへの同様のアプリケーションはありましたか？その時、どのようなデザインを選択しましたか?

JMS キューまたはトピックからのメッセージを並行して処理するために、メッセージ リスナまたはメッセージ駆動型 Bean のプールを作成することは可能ですか?

JBoss と JBoss の JMS を使用しています