問題タブ [msmq]

MSMQ へのアクセスを提供する Java ライブラリについて何か提案があれば教えてください。J-Integra Java-COM ライブラリの試用版をダウンロードし、MSMQ サンプル アプリをビルドして実行しました。jMSMQ などのいくつかの JNI 実装に出くわしましたが、できれば JNI は避けたいと思います。

また、JNBridge (ActiveMQ を使用) などの .NET<->JMS 相互運用ソリューションについても調査しました。しかし、私たちの会社はキューイングを MSMQ に一元化することを決定したと思うので、それが理想的なソリューションです。

.NET 側で WCF (netMsmq または msmqIntegration) を使用したいと考えています。Java 側が WCF メッセージ (バイナリ エンコーディング) をどのように処理するかについては少し心配ですが、そこにはオプションがあるはずです (テキスト エンコーディングと MSMQ トランスポートを使用した customBinding?)。ほとんどの場合、Java で MSMQ にアクセスすることについて心配しています。

もう 1 つのオプションは、各キューの入力側に薄い Web サービス レイヤーを配置し、その方法で相互運用を実現することです。ただし、そこではパフォーマンスが少し懸念されます。

助言がありますか？誰の時間もありがとう。

私は C# と .Net Framework 1.1 を使用しています (古いものですが、この機能を継承しており、変換できません)。メッセージをトランザクション キューに配置しましたが、約 50% の確率でキューに入れられません。すべてのサービス パックがインストールされた状態で、ワークグループと Windows/XP Professional を実行しています。配信不能キューにもメッセージがありません。

どこを見ればいいですか？

これは説明するためのしかし、ここに行きます。

msmqの送信者と受信者がWCFを使用するプログラムを作成しています。http://msdn.microsoft.com/en-us/library/ms751472.aspxとhttp://msdn.microsoft.com/en-us/library/ms789028の組み合わせで、次のような障害ハンドルを実装しました 。 aspx

すべてがうまく機能します。キューを介して何百ものメッセージを実行し、すべてが処理されるテストケースも作成しました。10000にすると、タイムアウトが発生しますが、エラー処理は正常に機能するため、メッセージは数回再試行され、ポイズンキューに入れられます。

コードをチェックインして、他の開発者にリリースしました。キューの使用中に、次の問題が2回以上発生しました。

メッセージが正しく読み込まれなかった場合、（PoisonErrorHandlerクラスの）障害メッセージとして終了します。常に次の例外メッセージ（タイプFaultException）があります。EndpointDispatcherでのAddressFilterの不一致により、To'net.msmq：// localhost / private/adpqueue'のメッセージをレシーバーで処理できません。送信者と受信者のEndpointAddressesが一致していることを確認します。このエラーでは、Code.Name=SenderおよびCode.SubCode.Name=DestinationUnreachable

再試行回数がMsmqPoisonMessageExceptionになると、LookupIdを取得します。このlookupidを使用して、ReceiveByLookupId（lookupId）を実行します（標準のSystem.Messaging.MessageQueueクラスを使用）。これにより、InvalidOperationExceptionが発生します。

この後、サービスは自動的に再起動し、サイクルが再起動しますが、これが終了することはありません。（再起動後、キューのパージは停止しません）。

コンピューターの管理を開いて、キューにメッセージがあるかどうかを確認すると、メッセージは空です。しかし、テキストエディタでp0000001.mqファイル（C：\ WINDOWS \ system32 \ msmq \ storage内）を開くと、メッセージが表示されます。このファイルを削除すると、すべてが再び機能します。アプリケーションを使用して問題を再現することはできません（破損した.mqファイルを保存したため、問題を再現できます）。たまに発生するだけです。

これは実行可能な状況ではありません。-コードを使用してこの問題を解決する方法や、問題の発生を防ぐ方法について、誰かアイデアはありますか？-wcfサービスがメッセージを認識できるのに、LookupIdを含むMessageQueueが何も認識しないのはなぜですか？-LookupIdを使用してキューをクエリする別の方法はありますか？-この状況はどのように発生しますか？他のすべてのメッセージを見ることができます。

メッセージ キュー内のメッセージの有効期間をどのように制御しますか? デフォルトの有効期間は何ですか? メッセージ キューをローカルで実行してみましたが、システムを再起動するとメッセージが消えることがわかりました。これは、疎結合アプリケーションを構築する際のメッセージ キューの目的を無効にしませんか。メッセージが処理のために別のマシンに送信されると、翌日には利用できなくなるということですか。メッセージ キューイング システムのこれらの側面については明確ではないため、ここでのいくつかのガイダンスは高く評価されます。

メッセージキュー（MSMQ）をリッスンして処理するWindowsサービスを.Net2.0で作成したいと思います。

車輪の再発明ではなく、誰かがそれを行うための最良の方法の例を投稿できますか？一度に1つずつ処理するだけでよく、並行して処理する必要はありません（スレッドなど）。

基本的に、キューをポーリングする必要があります。そこに何かがある場合は、それを処理し、キューから取り出して繰り返します。これもシステム効率の良い方法でやりたいと思っています。

提案をありがとう！

SQL Server 2005 の CLR トリガーで、MSMQ 経由でメッセージをキューに送信することはできますか?

SQL Server プロジェクト タイプを使用していますが、追加できる参照として System.Messaging が表示されません。

基本的に、行がテーブルに書き込まれるときに何らかのアクション (印刷) を実行する必要があります。行を生成するデバイスは、基本的な操作のみを実行できるハンドヘルド スキャナーです。そのうちの 1 つは、odbc を介した SQL サーバーへの書き込みです。最初のアイデアは、テーブルをポーリングし、レコードを取得し、レコードを印刷し、レコードを削除することでした。これはおそらく問題なく動作しますが、メッセージ キューについて学習する良いケースと言い訳のように思えました。

TIBCORendezvousとMSMQの違いを教えてください。

NetMsmqBinding を使用して WCF サービスを作成し、Windows Activation Service (WAS) を使用して IIS7 でホストしました。

現在（完全に動作します）：

次の IIS でホストされます。http://localhost/MyService/MyService.svc

サービス エンドポイント アドレスの場合:http://localhost/private/MyService/MyService.svc

対応するキュー:.\private$\MyService/MyService.svc

望ましい（何もせず、エラーメッセージも出さない）：

次の IIS でホストされます。http://localhost/MyService.svc

サービス エンドポイント アドレスの場合:http://localhost/private/MyService.svc

対応するキュー:.\private$\MyService.svc

MyService IIS アプリケーションを使用すると、すべてが完全に機能します。しかし、「MyService」アプリの代わりにルート「/」アプリを使用してサービスをホストしようとすると、同じセットアップ (コード、IIS セキュリティ、キュー セキュリティなど) は何もしません。イベント ログにエラーはありません。着信メッセージはキューにそのまま残ります。

IIS7 サイトのルート アプリケーションでは、WAS によってアクティブ化されたサービスのホスティングがサポートされていますか?

今後のプロジェクトで非同期実行を行うためのソリューションとして MSMQ を使用することを検討しています。WCF と MassTransit などのフレームワーク、または手書きの MSMQ クライアントを使用して、MSMQ からタスクを配置/読み取りすることの違いを知りたいです。

基本的に、アプリケーションは複数の Web サイト (LAN を介した内部またはインターネットを介した外部) であり、サービス層 (WCF または通常の Web サービス) を介してデータを読み書きします。次に、このサービス レイヤーは次の 2 つのいずれかを実行します。1. データベースにデータを書き込む 2. メッセージをキューに入れることでバックグラウンド プロセスをトリガーします。3. 明らかに、データベースからデータを取得することもできます。キューの反対側にある小さなエージェント (Windows サービス) は、キューを監視し、タスク コマンドに基づいて実行します。

このアーキテクチャは、スケーリング (キューとエージェントの追加) が非常に簡単で、RPC や分散実行などに比べて実装が簡単です。また、エージェントの処理はリアルタイムである必要はありません。また、エージェントとサービス層は、共通のドメイン オブジェクトとリポジトリなどを共有することを除いて、別個のアプリケーションです。

どう思いますか？上記の要件に対するアーキテクチャの提案を歓迎します。ありがとうございました！