問題タブ [ordered-delivery]

WCF netMSMQbinding を使用すると、順序どおりの配信を保証できますか?

挿入コマンドに続いて多数の更新コマンドを同じキューに入れていますが、時折、更新の 1 つが挿入よりも優先されます。

広範なログを追加すると、それらが正しい順序でキューに追加され、異なる順序で処理されていることが明らかです。

この動作が予想されることを示すいくつかの記事を Google で検索しましたが、どうにかして順序付けられるように構成する必要があるようです。

私たちのキューはトランザクションであるため、シーケンス番号を追加して宛先で再シーケンスすることは機能しないと思います。トランザクション性が失われるためです。

属性を追加する[DeliveryRequirements(RequireOrderedDelivery=true, QueuedDeliveryRequirements=QueuedDeliveryRequirementsMode.Require)]と、次のエラーが発生します。

コントラクト「IService」の DeliveryRequirementsAttribute は、NotAllowed の QueuedDeliveryRequirements 値を指定します。ただし、このコントラクト用に構成されたバインディングは、キュー配信をサポートすることを指定しています。キューに入れられたバインディングは、このコントラクトでは使用できません。

すべてが正しくセットアップされているように見えるため、このエラーが発生する理由がわかりません。ただし、この設定がMSMQで許可されていることを確認することはできませんでした.WS-RM設定のようであり、知る限りnetMSMQBindingはWS-RMをサポートしていません.

入力されるメッセージの順序が非常に重要であり、保持する必要がある BizTalk アプリケーションがあります。つまり、同じ順序で出力する必要があります。通常、注文された配達はここでうまくいきます。

ただし、注文された配信は、受信場所を送信ポートに直接接続した場合にのみ保証されると読みました。オーケストレーションを使用した時点で、注文の配信は保証されなくなります。これを回避または修正する方法はありますか? この種のものはアプリケーション全体を台無しにするため、私たちは何ヶ月もこれに取り組んできました.

Microsoft からの回避策を読みました。ここでは、カウンターを持つ追加のフィールドを使用し、カウンターをチェックするエンド オーケストレーションを使用しています。しかし、これは私たちが今行うにはあまりにも多くの作業です。したがって、この回避策はありません。さらに、すべてのメッセージが翻訳されるわけではないため、フローに穴が開いたり、すべてのメッセージが同じソースから来ているわけではないため、この回避策はとにかく役に立たなくなります。

他のアイデアはありますか？

別の注文配送の問題。

true の配信を注文した送信ポートにバインドされているオーケストレーションがあります。別の送信ポートもフィルタリングによってこれらのメッセージを取得し、このポートも配信を順序付けています。

何らかの理由で、メッセージを使用する複数のポートがあり、そのうちの 1 つが直接ポート バインドされている場合、ポートの 1 つだけが使用されます。つまり、両方のポートが出力を提供するわけではありません。

常に出力されているポートの 1 つを登録解除すると、これは両方の方法で機能します。

代わりにフィルターを使用する 2 つのポートでこれを使用していましたが、これは機能しましたが、1 つを直接ポートに変更する必要があり、それ以来問題が発生しました。また、BizTalk のポートの選択はかなりランダムです。たとえば、私たちのサーバーではポート A が選択され、ローカル マシンで同じ問題を再現すると、たとえばポート B が選択されるためです。

これは一種の奇妙な問題であり、何が原因であるかはわかりません。

メインのオーケストレーションが一連のメッセージの処理を担当している状況があります。これらのメッセージは一連の顧客に属し、オーケストレーションは受信したメッセージを読み取り、新しい顧客 ID が見つかるたびに、特定の顧客のメッセージの処理を担当する新しいオーケストレーションを起動します。受信したメッセージの順序を保持する必要があるため、新しく作成されたオーケストレーションはメッセージを処理し、メインのオーケストレーションからの追加メッセージを待機する必要があります。

これに取り組むためにさまざまな方法を試みましたが、うまく実装できませんでした。これをどのように行うことができるかについて、ご意見をお聞きしたいと思います。

ありがとう。

シナリオは次のとおりです。

2台のマシン：「マシンA」と「マシンB」。

対応するIPアドレスが192.168.0.100（Aの場合）と192.168.0.200（Bの場合）であるとしましょう。どちらのマシンにも、WindowsServer2008のMSMQがインストールされています。

マシンA

次のキューが構成されています：private$\aaa、transactional。

そのキューに単一のコンシューマーがありRead、MSMQトランザクションのすべてのアクションをラップし、「現在の」メッセージからのみ読み取ります（つまり、カーソル操作は使用されません）。

マシンB

にメッセージを送信する単一のアプリケーションがありますFormatName:direct=os:192.168.0.100\private$\aaa。各Sendメッセージは、（C＃のコード）を使用してMSMQトランザクションでラップされます
TimeToReachQueue = Message.InfiniteTimeout
。
TimeToBeReceived = Message.InfiniteTimeout

そして...質問

このシナリオとの構成ではprivate$\aaa、BからAに送信されるメッセージは次のとおりです。

1. 一度お届けしますか？つまり、マシンAのコンシューマーアプリケーションで、「現在の」メッセージが実際に「新しい」（つまり、以前に処理されていない）ことを確認する必要がありますか？それとも、MSMQ自体がその問題を処理しますか？キューだからちょっとばかげているね！しかし、メッセージが正しいと主張する具体的な参考資料は見つかりませんでした。私はそのような主張を見ましたが、Microsoftの公式リソースからではありません。
2. 順番に？つまり、M1ネットワークの問題が原因でBからAにメッセージを送信できず、ネットワークが正常に戻って、次のメッセージM2がマシンAに正常に送信される可能性はありますか？

どうもありがとう！