問題タブ [message-queue]

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 投票する
1 に答える
429 参照

data-structures - 遅延メッセージを配信し、一意性をチェックするメッセージキュー

着信イベントを受信するオンラインサービスがあります(毎秒数回)。30秒以上イベントがなかった場合、サービスはジョブを処理する必要があります。サービスは複数のPCに分散され、Amazon Webサービス(SQSおよびSimpleDB)をバックボーンとして使用します。

着信イベントがある場合(メッセージをメッセージキューに入れるだけで完了)にジョブをスケジュールする方法は理解していますが、条件が「X秒のイベントなし」の場合にジョブをスケジュールするにはどうすればよいですか?

理想的には、重複メッセージを許可せず、将来のスケジュールを設定し、各メッセージの「配信日」を調整できるメッセージキューが必要です。

そのようなメッセージキューの実装はありますか?この問題は、データベースに一部のデータを保持しなくても解決できますか?

ありがとうございました

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

message-queue - 単純なキュー/ミューテックスではなく、なぜ ActiveMQ なのか?

明日は、インプロセス メッセージ キューの実装を選択する理由を説明しますが、その理由を明確に説明することはできません。私の共同設計者は、ジョブの基本的なリストとミューテックスを使用してアクセスを制御する単純な非同期キューを実装することを提案しています。私は組み込みモードの ActiveMQ を提案しています。私は個人的に ActiveMQ に非常に感銘を受けました。私の直感的な印象を裏付けるために、いくつかの適切で確固たる議論をしたいと思います。

それが重要な場合、アプリケーションは基本的に 1 つのプロデューサー/n 人のコンシューマーであり、処理される個々のジョブに固有の優先度とタイプの情報があります。

これまでのところ、ソリューションの管理性と拡張性は強力な議論になっていないことに注意してください。誰かが私の主張にもっとパンチを与えてくれたら嬉しいです. フォーラムはそれについて私を助けることができますか?

0 投票する
5 に答える
4571 参照

windows - Win32イベント駆動型プログラミングは内部でどのように実装されていますか?

Win32 C ++アプリケーションでは、キューからメッセージをフェッチし、それらを変換してからディスパッチするメッセージループを開始します。最終的に、各メッセージはWndProcに到達し、そこで関連するイベントを処理できます。

私はその部分を理解しています。私が理解していないのは、進行の合間です。具体的には:

  1. さまざまな種類のOS割り込みハンドラーが、前述の「メッセージキュー」にメッセージを配置する必要がありますが、このキューはプロセスアドレス空間内のどこにありますか?割り込みハンドラコードにどのように公開されますか?
  2. メッセージを「翻訳」するとはどういう意味ですか?呼び出しはTranslateMessage()実際に何をしますか?
  3. によってディスパッチされるDispatchMessage()と、メッセージはWndProcに到達する前にどの場所でスイングしますか(つまり、OSはそれをどのように処理しますか)?

上記の答えをご存知の方がいらっしゃいましたら、好奇心を満たしてください。ありがとう。

0 投票する
10 に答える
1149 参照

c++ - より多くのスレッド、より良いパフォーマンス?

メッセージ駆動型アプリを作成するとき。内部操作にメッセージングを広範囲に使用するという点だけが標準のWindowsアプリと同じように、スレッド化に関して最善のアプローチは何でしょうか。

私が見ているように、基本的に3つのアプローチがあります(他のセットアップを念頭に置いている場合は、共有してください)。

  1. シングルスレッドですべてのメッセージを処理します。
  2. 個別のメッセージタイプ(一般、UI、ネットワークなど)に個別のスレッドを使用する
  3. 単一のメッセージキューを共有および処理する複数のスレッドを持つ。

では、3つの間に大きなパフォーマンスの違いはありますか?一般的な考え方は次のとおりです。明らかに、最後の2つのオプションは、複数のプロセッサが存在する状況から恩恵を受けます。さらに、いずれかのスレッドが外部イベントを待機している場合でも、他のスレッドは無関係のメッセージを処理できます。しかし、それを無視すると、複数のスレッドはオーバーヘッドを追加するだけのようです(より複雑な同期状況は言うまでもなく、スレッドスイッチ)。

そして別の質問:このようなシステムを標準のWindowsメッセージングシステムに実装することをお勧めしますか、それとも別のキューメカニズムを実装することをお勧めしますか?その理由は何ですか?

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

java - Windows の場合 - 使用する mqji.properties はどこにありますか?

私のアプリケーションは、顧客がダウンロード、インストール、実行するスタンドアロンの Java アプリケーションです。MQ を使用して、何年も稼働しているホストと通信します。私自身も顧客も、Windows マシンに MQ をインストールしていません。com.ibm.mq.jar を含めて使用して作業を行います。

どうやら、MQ はこれを防ぐためにクラスパスに mqji.properties ファイルを必要とします。

だから私の質問は:どこで入手できますか??

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

c++ - メッセージの処理が遅すぎるため、UIがぎくしゃくして応答しなくなります。これを軽減するために、複数のスレッドを使用するにはどうすればよいですか?

アプリをユーザーの操作に応答させ続けるのに問題があります。したがって、メッセージ処理を複数のスレッドに分割したいと思います。

単純に複数のスレッドを作成し、それらすべての同じメッセージキューから読み取り、どのスレッドでも各メッセージを処理できるようにすることはできますか?

もしそうなら、これはどのように達成できますか?

そうでない場合は、この問題を解決する別の方法を提案できますか?

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

data-structures - 高性能で自動的にバックアップされるキューの構築

私の問題に関するヒントを教えてください。

次のようなキュー データ構造を構築しています。

  1. リアルタイムでハードディスクにバックアップがあります
  2. バックアップを復元できます
  3. 大量のエンキュー/デキュー要求に対応可能

ありがとうございました!

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

.net - Persistent Messaging/Service Bus - 自作するか、学習曲線を危険にさらすか?

さまざまな通知のためにサーバーにメッセージを送信する必要があるクライアント アプリケーションがあります。クライアントが時々接続して実行できるようにするために、メッセージ キュー アプローチを使用します。キュー処理は、メッセージをキューから取り出し、別のキューに配置して最終的に処理する Web サービスを呼び出します。この質問はクライアント環境に関するものです。サーバー環境はすでに決まっています。

MSMQ を適切にインストール/構成し、セキュリティで保護するためにすべてのクライアント PC を制御できないため、MSMQ を使用したくありません。また、MSMQ キューの内容を調査するためのツールの品質のために、サポートがより困難になるためです。 . SQL Server 2005 Express はすべてのマシンにあり、アプリケーションのデータを格納するために使用されます。

私は現在、2つのオプションにそれを持っています:

  1. メッセージをシリアル化した後にテーブルに格納し、ThreadPool.QueueUserWorkItem各メッセージ タイプに対して構成されたハンドラーによってメッセージを処理するために使用する、かなり基本的な永続的なメッセージ キューを記述します。すべてが含まれているSystem.Transactions.TransactionScopeため、正常に処理された場合にのみ永続キューから削除されます。
  2. ローカル データベースを使用する Service Broker トランスポートを使用して、クライアントで NServiceBus (これはチームとして使用したサービス バスであるため、MassTransit などはオプションではありません) を使用します。

私はサービス バスの経験がほとんどないため (サービス バスの用語はまだよくわかりません)、必要な方法で要件を満たすはるかに単純なものを作成する場合と比較して、学習曲線が心配です (展開は大きな考慮)。

誰か考えがありますか?

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

java - MQJE018: プロトコル エラー - 予期しないセグメント タイプを受け取りました

すべての MQ 達人に呼びかけます。

デスクの下に、次のような本番環境を複製するために使用するボックスがあります。

WebSphere 6.1 フェドラ Linux MQ 6.0

アプリケーションの 1 つが MQ キューにメッセージを送信しようとするたびに、次のエラーが発生します。 MQJE018: プロトコル エラー - 予期しないセグメント タイプを受信しました

これが何を意味するかについての提案をいただければ幸いです。スタック トレースを以下に示します。

EDIT:私はIBMのドキュメントで理由コードを調べましたが、ほとんど役に立ちません