問題タブ [mq]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
10938 参照

java - MQ on Javaの使用を開始する:どこから始めればよいですか?

私はいくつかのレガシー接続を新しいアプリケーションの1つに詰め込もうとしています。これは、MQへの最初の進出です。MQを介して配信されるXMLメッセージを受け入れるミドルウェアサーバーがあります。これを私たちの古い記録システムに対する独自の要求に変換し、同様のXML形式で応答キューに応答を配信します。

入力と出力のXML構造、およびMQホスト、ターゲットキュー、応答キューのサンプルがあります。私が持っていないのは、どこから始めるべきかについての手がかりです。

OpenMQまたは他の無料のMQライブラリの1つを使用して単純な要求/応答メカニズムを構築するために利用できる適切なチュートリアルはありますか?

ありがとう!

0 投票する
2 に答える
2929 参照

delphi - Delphi + メッセージ キュー

Delphi でメッセージ キューイングを使用する無料のソリューションはありますか?

Habari(無料ではない)について知っているだけですが、インターネット上で無料のソリューションを見つけることができませんでした.


私のトピックを閉じるための投票について。質問をしているのですが、ここでそれが何であるかを説明する必要がある場合、おそらく答え方がわからないでしょう。Daniele や Jeroen Pluimers のように、私が話していることを知っている人なら問題なく答えることができます。

しかし、MQ とは何かを知らない人のために: ここでその基本を学ぶことができます : http://mq.java.net/overview.html HornetQ、GlassFish、RabbitMQ など...そしてご存知のように、ブローカーと話をするにはクライアントが必要です。私が探しているのはこのクライアントです。この場合、オプションの 1 つ (いくつかのオプション) はhttp:/ /www.habarisoft.com/habari_openmq.html .

Tks

0 投票する
1 に答える
1820 参照

java - SpringのDefaultMessageListenerContainerを使用して手動コミットを行う方法は?

メッセージをキューでリッスンするアプリケーションがあり、dmlcがsessionTransactedプロパティを提供していることを知っています。これにより、メッセージ受信イベントを手動でコミットできると思いますが、リスナーでそれを活用する方法がわかりません。

RuntimeExceptionをスローするだけで、メッセージはキューに戻され、ErrorHandlerが設定されていない場合はループに入るようですが、受信を具体的にコミットしたいと思います。

例えば

0 投票する
3 に答える
2413 参照

c - スレッドはキューから他のスレッドの IPC メッセージを取得します (Linux)

Linux に 2 つの異なる IPC メッセージ キューがある場合、間違ったキューからのメッセージが取得されることがあります。

次のおもちゃのプログラムは問題を表示します。異なるプロセッサで繰り返すことができます。

どんな助けでも大歓迎です!

バート

0 投票する
2 に答える
5921 参照

java - MQ でメッセージが失われないようにする方法

LINUX 環境で実行され、SYNCPOINT を使用して MQ でトランザクションを実行する Java アプリケーションを作成しています。Websphere MQ Java クラスを使用して、MQ サービスと対話します。私のコードでやっていることは次のとおりです(疑似):

基本的に、メッセージを取得して処理し、データベースに保持してから、queueManager でコミットを呼び出します。プロセスは、グレースフル シャットダウンを実行するために、TIBRV でメッセージをリッスンします。

メッセージが失われないことを確認するためにプロセスをテストしています。20,000 件のメッセージをキューに入れ、プロセスを実行します。処理中にグレースフル シャットダウン コールを実行します。次に、キューにあるメッセージの量とデータベースにあるメッセージの量を比較します。TIBRV メッセージを介して正常なシャットダウンが発生した場合、MQ メッセージの数 + DB メッセージの数 = 最初にキューにあったメッセージの合計。

ただし、killまたはを実行するkill -9と、メッセージが失われることがわかります。私は常に合計 19999 件のメッセージという結果になります。

このメッセージがどのように失われているかを調べる方法はありますか? Websphere App Server で注意すべきことはありますか?

0 投票する
3 に答える
857 参照

c# - Microsoft の MQ シリーズのバージョンは何ですか?

大学では、キューに永続化されるメッセージを送信できるミドルウェアである IBM の MQ シリーズを研究しました。MQ Series には、保証されたメッセージ配信と呼ばれるものがありました。つまり、キューに送信されたメッセージを取得すると、キュー メッセージを含むサーバーの電源がオフになり、再びオンになった場合でも、キューは保持されます。

Microsoft には、C# と SharePoint で動作する同様のテクノロジがありますか?

0 投票する
3 に答える
547 参照

java - 一般に、MQ パブリッシュ/サブスクライブ ドメイン固有のインターフェイスは、ポイント ツー ポイントよりも高速ですか?

ポイントツーポイント MQ 通信でトランスポート層を使用する既存のアプリケーションに取り組んでいます。

指定されたアカウントのリストごとに、いくつかの情報を取得する必要があります。

現在、MQ と通信するために次のようなものがあります。

ご覧のとおり、次のアカウントに進む前に、完全に終了するまで待ちます。パフォーマンスの問題のため、再加工する必要があります。

現時点で考えられるシナリオは 2 つあります。

1) アプリケーション内で、アカウントごとにトランスポート アダプターを実行する一連のスレッドを作成します。次に、各タスクからデータを取得します。私はこの方法を好みますが、一部のチーム メンバーは、このような変更にはトランスポート層が適していると主張しており、アプリケーションではなく MQ に余分な負荷をかける必要があります。

2) パブリッシュ/サブスクライブ モデルを使用するようにトランスポート層を作り直します。理想的には、次のようなものが必要です。

次に、ループ内でリクエストを送信し、後でループ内でデータを取得します。アイデアは、最初のリクエストがバックエンド システムによって処理されている間、応答を待つ必要はなく、代わりに次のリクエストを送信するというものです。

私の質問は、現在の順次検索よりもはるかに高速になるということですか?

0 投票する
2 に答える
2917 参照

scala - akka アクターでのメッセージ配信シーケンス

私は Akka にかなり慣れていないので、リファレンス マニュアルで答えを見つけることができませんでした。

3 台のマシン (A、B、C) のクラスターにリモート アクターが分散しているとします。この場合、各マシンには 1 つのアクターが存在し、他の 2 つのアクターには他の 2 つのアクターへのactorRef があります。

アクター A は次のコードを実行します。

アクター B は、メッセージ ハンドラーで次のコードを実行します。

アクター C は、メッセージ ハンドラーで次のコードを実行します。

次の仮定を立てることができますか (もしあれば):

  1. アクター B は、msg2 を取得する前に msg1 を取得します

  2. アクター A は msg4 を取得する前に msg5 を取得します

そして、おそらく上記の理解につながるフォローアップの質問: Is message sent by the ! オペレーターはネットワークを介して真に非同期に処理するのか、それとも受信メールボックスがそれを取得するまで待機するのか? つまり、行を行います

アクター B がメールボックスにメッセージを取得するまでブロックするか、配信を処理して実行を続けるスレッドを生成するか

アクター B が msg1 を受け取ったことを知る前に?

0 投票する
2 に答える
4479 参照

xml - MQ ベースのバッチ アプリケーションのパフォーマンスを向上させるにはどうすればよいですか?

メッセージが 1 時間あたり 70K XML の割合で受信し続けるアプリケーションがあります。これらの XML メッセージを消費し、中間キューに格納します。すべてのメッセージを 24 時間で消費するという SLA を満たす必要があるため、中間キューが作成されます。24 時間以内に XMLS を使用して内部キューにロードできます。内部キューにロードした後、XMLS を処理し (解析し、ほとんど変換を適用せず、ほとんど検証を実行しません)、データを高度に正規化されたデータ モデルに格納します。データモデルがパフォーマンスに大きな影響を与える可能性があることはわかっていますが、残念ながら、データモデルを制御することはできません。現在、2,000 件のメッセージを処理するのに 3.5 分かかっており、これは許容できません。2K メッセージの場合は 1 分に短縮したいと考えています。これまでに行ったことは次のとおりです。

1) 該当する場合は適用指数。
2) XML の解析に XMLBeans を使用します (各 XML のサイズはそれほど大きくありません)
3) 不要な検証、変換などをすべて削除し ました。

アプリケーションの実行環境:
オペレーティング システム: RHEL 5.4 64 ビット
プラットフォーム: JDK 1.6.0_17、64 ビット
データベース: Oracle 11g R2 64 ビット (2 ノード クラスター)
外部 MQ: IBM キュー
内部一時ストレージ MQ: JBoss MQ
アプリケーション サーバー: Jboss 5.1 .0.GA (EAP バージョン)

XML メッセージを消費して処理する順序は非常に重要であるため、並列処理を行うことはできません。

パフォーマンスを向上させるために他にできることはありますか?