問題タブ [msmq-wcf]

約10の異なるメッセージをエンキューしてから、デキュー/処理する必要があるシナリオがあります。1人のサブスクライバーは10個のメッセージすべてを必要としますが、別のサブスクライバーは10個のメッセージのうち8個だけを必要とします。このタイプのアーキテクチャをセットアップするための最良の方法を理解しようとしています。メッセージタイプごとにキューを作成して、サブスクライバーが関連するキューをサブスクライブできるようにしますか、それともすべてを同じキューにダンプして、そのサブスクライバーに関連しないメッセージを無視しますか？ソリューションが柔軟でスケーラブルであることなどを確認したい。

プロセス：

1. 10個の異なるxmlメッセージがIBMWebSphereMQサーバーにエンキューされます。
2. .Netを使用します（WebSphere MQ 7.1がWCFサポートに追加されたため、おそらくWCFです）
3. メッセージをデキューし、別のバックエンドDB（ほとんどの場合SQL Server）にロードします。
4. 非常に多くのメッセージを処理するため、ソリューションを適切に拡張する必要があり、これは増大する可能性があります（おそらく40〜50,000 /時間）。少なくとも私たちにとっては多額です。

いつものように情報を大いに感謝します。

--S

システム全体に多数の MSMQ キュー (プライベート キューとパブリック キューの両方) があります。キューから読み取る Windows サービスがクラッシュすることがあるため、そのキューにメッセージが蓄積されます。キューが特定のサイズ (おそらく 60K メッセージ) に達すると、そのサーバー上のすべてのキューが機能しなくなり、リソース不足に関するエラーがスローされます。

私の質問は、キューが舞台裏で実際にどのように機能しているのか、メッセージを RAM またはハード ドライブに保存しているのかということです。サーバーの RAM が不足すると、リソースが不足してクラッシュしますか? ハードドライブに割り当てられたスペースを使用している場合、許容サイズを増やす方法はありますか? RAM を使用している場合、サーバーに RAM を追加するだけで許容サイズを増やすことができますか?

サービスがダウンした場合、サービスの修正に取り組んでいる間、そのキューに 100K または 200K のメッセージを格納できるようにする必要があります。これらのメッセージはビジネスにとって重要だからです。

ワークフロー (WF4) で実行時間の長い WCF サービスを呼び出し、WCF サービスの完了時に処理を再開しようとすると問題が発生します。下の図は、私が達成しようとしていることの大まかな概要を示しています。このシナリオ (または非常に類似したもの) を示すサンプルを教えていただければ、非常にありがたいです。参考までに、実際には役に立たなかった WF から WF への例をたくさん見てきました。

これは簡単な質問ですが、答えを見つけることができませんでした。

メッセージが再試行キューに入れられたとします (再試行キューを作成するのは誰ですか?それは WCF または MSMQ サービスですか?)。

5 分後 (これが私の再試行の遅​​延です)、そのメッセージはアプリケーション キューに戻ります。

質問: タイムアウト後にメッセージを再試行キューからアプリケーション キューに移動するのは誰ですか?

おまけの質問: 遅延はどのように追跡されていますか? メッセージは「移動」タイムスタンプと「再試行」タイムスタンプを取得しますか?

IIS/WAS でホストされている場合、net.msmq 用に構成された WCF サービスは HttpApplication として実行されないことを理解しています。つまり、Global でイベントを取得できません (Application_Start が重要です)。この点で私は正しいですか？

Windows Server AppFabric を使用してサービスを自動開始すると、HTTP 経由でサービスがヒットし、Application_Start イベントが発生しますか? もしそうなら、これは信頼できますか？

私の本当の質問は、非 HTTP WCF サービスの初期化コードの「適切な」場所はどこですか?

特に（適切な場所はものごとに異なる場合があるため）：

• IoC 登録
• log4net 初期化
• MSMQ キューがローカルに存在することを確認する (Juval Lowy が WCF の本で提案しているように)

後続の質問: カスタム IServiceBehavior のイベントは、すべての要求で発生しますか、それとも起動時に 1 回だけ発生しますか? ServiceHost.OnOpening() はどうですか - すべてのリクエストまたは起動時に 1 回だけですか? （私のテストでは、それは一度だけですが、どこにも見つからないように見えるため、WCFの「ライフサイクル」が文書化されている場所を知っている人はいますか。）

WCF でアクティブ化されたワークフロー サービス (XAMLX) のセットアップがあります (WorkflowServiceHost を使用してホストされています)。

この WCF WebService には、'NetMsMqBinding' バインディングと、クライアントが操作をスケジュールするために使用する net.msmq ベースのエンドポイントがあります。

クライアント側では、Visual Studio を使用してプロキシ スタブを生成し、この WCF サービスと通信しました。すべてが正常に機能しており、サーバー上の (ジャーナリングされた) MQ にメッセージが表示され、WCF がキューからメッセージを取得して、メッセージに基づいて構成されたワークフローをアクティブにすることがわかります。

MQ に送信されるメッセージの優先順位を制御して、特定の WCF クライアントがワークフローの処理を優先できるようにする必要があります。

NetMsMqBinding は実際には MQ メッセージの優先順位付けをサポートしていないようです。これは正しいです？もしそうなら、どうすればこれを達成/シミュレートできますか? MQ トリガーを使用して、フラグに基づいてメッセージの優先度を変更できますか?

MSMQまたはWCFの専門家ではないので、私はそれについてかなり読んだことがあり、それは音と見栄えが良いです。私は何かを開発しようとしていますが、最終的には、堅牢で耐久性が必要な理論を最初に開発しようとしています。

MSMQは別のサーバーでホストされると思います。

2つのWCFサービスがあります。1つは受信メッセージ用で、もう1つは送信メッセージ用です（メッセージを取得し、内部処理/検証を行ってから、送信メッセージキューに配置するか、電子メール/テキストメッセージなどを送信します）

正しい構成で理解しているので、システムをトランザクション処理可能（メッセージが失われることはありません）で、1回だけ送信できるため、メッセージが重複する可能性はありません。

アプリケーション/サービスはメッセージを処理するためにマルチスレッド化され、メッセージは数百、数千になります。

しかし、メッセージの処理中またはサービスの存続期間中、サーバーがクラッシュした場合はどうなりますか？サーバーが再起動した場合はどうなりますか？何らかの理由でサービスが例外をスローした場合はどうなりますか？そのメッセージを失わないようにするにはどうすればよいのでしょうか。しかし、メッセージが再び処理されるのを待つために、メッセージをキューに戻す方法はありますか。また、サービスが再び生成されるように、サービスが堅牢であることを確認するにはどうすればよいですか？

ここでアドバイスや詳細をいただければ幸いです。取り入れるべきものは非常に多く、WCF/MSMQは非常に多くのオプションを公開しています。

何百ものダウンロードと変換を一緒に処理するWCFサービスを開発しようとしています。ASP.NETWebアプリケーションからメッセージを受信するトランザクションキューを使用してMSMQを初期化しました。

インターネットに関する長い調査の後の私の質問は、MSMQメッセージを管理するWCFサービスメソッドで長いプロセスを管理する方法です。

問題は、小さいサイズでダウンロードすると、プロセスがすぐに終了し、スコープがMSMQサービスに完全に戻ることです。ただし、ダウンロードサイズが大きく、ダウンロードに3/4分かかる場合は、スコープがまだ完了していますが、 MSMQサービスがMSGをWCFサービスに再送信しましたが、ダウンロードが重複しています。

これはタイムアウトの問題だと思いますが、ホストapp.configをより適切に構成しようとしましたが、成功しませんでした。

これは、WCFサービスへのメソッドです。

アップデート

長い試行錯誤の末、MSMQキューによって起動されるメソッドに長いプロセスを組み込むことは不可能だと思い始めています。

データを管理する別のスレッドを使用して回避しますが、問題は、ジョブが新しい​​スレッドに渡されると、MSMQがメッセージを削除したため、TransactionScopeの利点が失われることです。

多くの通信サーバーがデータパケットを送信しています。これらのサーバープログラムからのこれらのデータパケットは、アップデーターが処理するまでMSMQに保存します。データの損失が懸念されており、これらのサーバープログラムからのデータパケットを失わないようにし、効率的でパフォーマンスの高いソリューションを求めています。

最良の設計アプローチは何でしょうか？

私はこのシナリオを持っています、みんな-

次のビジネス トランザクションが表示される典型的な大規模 CMS アプリケーション:

• ユーザーはすぐにコンテンツを公開します。
• ユーザーはコンテンツの公開をスケジュールします。
• 自動プロセスは、たとえば 10 分間隔で実行され、スケジュールされた準備完了(単に BO のステータス) のコンテンツを収集し、公開に送信します。

これは、実際のシステムの単純化された説明です。パブリッシュとは、呼び出し引数の構築、別の Web アプリ (asp.net) の実行による html コンテンツの生成、トランザクション パーティのコミット、およびパブリッシュ結果に関するユーザーへの通知という4 つの主要なサブシステムで構成される複雑なプロセスを意味します。したがって、システムはプロセス全体を単一のメガトランザクションで実行する能力を失います。つまり、可能ですが、スケーラビリティ/パフォーマンスの観点からは実用的ではありません。

サブシステムが相互に通信するためのオプションがいくつかあります。たとえば、MSMQ、SQL Service Broker、NServiceBus、プレーンな WCF の一方向呼び出しのチェーン (現在実装されています) を利用するなどです。ユーザー数の増加に伴い、システムがより忙しくなり、より多くのコンテンツが生成されるように見えるため、この処理のためのより信頼性が高くスケーラブルなソリューションを探しています。特に、クライアントからモバイル版のサポートが要求されたことがあります。

私の考慮事項の 1 つは、専用の WCF サービスがコンテンツ生成モジュール (Web アプリ) の隣にディスパッチする MSMQ を使用して、すべてのユーザーの即時要求をキューに入れることです。Windowsのスケジュールされたタスクも同様です。これらのメッセージング プラットフォームがどのように役立つかはわかりませんが、html 生成の前にそれらが存在するわけではありません。これは本当に私を混乱させます。

どのテクノロジーがこれに最適かを自分で判断することはできません.どんな助け、考慮事項、あなたの経験を共有することも私を助けます.