問題タブ [wcf-callbacks]

netTcpBinding を介した二重 WCF サービスがあります。このサービスは、クライアントが Subscribe/Unsubscribe メソッドを使用したコールバック実装でサービスにサブスクライブするサブスクリプション モデルを使用します。

このサービスには、データベースからユーザーを認証し、IAuthorizationPolicy.Evaluate() メソッドでデフォルトのスレッド プリンシパルをカスタム プリンシパルに設定するカスタム IAuthorizationPolicy があります。

このサービスは、Windows 7 の LOCALSYSTEM ID の下で、IIS 7.5 のサービスとして実行されています。

まず、クライアント (WinForms) がユーザーを認証する方法は次のとおりです。

1. ログオン フォームを表示して資格情報を要求する
2. 別のエンドポイントで別の認証サービスを呼び出して、ユーザー資格情報を検証する
3. AppDomain.SetThreadPrincipal を使用して既定のスレッド プリンシパルを設定する

私が直面している問題は、コールバック スレッドで、コールバック スレッドでのみ、Thread.CurrentPrincipal が匿名の GenericPrincipal オブジェクトにリセットされ、認証後に設定されたカスタム プリンシパルが伝達されないことです。

更新: securityMode と clientCredentialType を "None" に設定すると、プリンシパルは期待どおりに伝達されます。明らかに、これはセキュリティ構成と関係があります。構成の組み合わせをたくさん試しましたが、うまくいきませんでした。

更新:問題を再現するサンプル プロジェクトを含めました。

このソリューションは、すべてが構成され実行されているので簡単で、数回クリックするだけで貴重な時間が数分かかります。5 つのプロジェクトが含まれています。

1. PM.Services - WCF サービス プロジェクト
2. PM.Contracts - サービス コントラクトを含むライブラリ
3. クライアント/ブロードキャスター- コンソール アプリケーションは、サービスを通じて他のクライアントにブロードキャストします。
4. クライアント/リスナー- サービスにサブスクライブする/ブロードキャストをリッスンするコンソール アプリケーション(ここで Thread.CurrentPrincipal がリセットされます)。
5. Client/Shared - コールバックの実装とサービス作成コードを含む 2 つのクライアント間で共有されるライブラリ。

マシンでサービスを構成するには (マシンで IIS7 以降が既に有効になっていると仮定)、ソリューション ルート フォルダーには次の 2 つのバッチ ファイルが含まれます。

InstallService.bat:このバッチは:

• コンピューターで次の Windows 機能とその親機能を有効にします (まだ有効になっていない場合): Windows Communication Foundation HTTP ActivationとWindows Communication Foundation Non-HTTP Activation。WCF と net.tcp を有効にします。

• TrustedPeople ストアにサービス証明書を作成して追加します。

• 7359 (http) および 7357 (net.tcp) でリッスンするサービスの Web サイトを作成します。

• LOCALSYSTEM ID の下に ApplicationPool を作成します (テスト中のアクセス許可の問題を回避するため)。

• c:\inetpub\WCFCallbackSample にフォルダーを作成し、サービスの出力をそこにコピーします。

UninstallService.bat : このバッチは次のことを行います。

• TrustedPeople ストアからサービス証明書を削除します。

• サービス Web サイトをアンインストールします。

• Web サイト フォルダーを削除します。

サンプル ソリューションの実行:

• ソリューションを構築する

• InstallService.bat を使用してサービスをインストールします。

• ソリューションをデバッグ/実行して、2 つのサービス コンシューマー (Client\Broadcaster、Client\Listener) を実行します。

• ブロードキャスターからメッセージを送信する

• リスナーでは、(コンソールに表示される) コールバック スレッドの ID が、アプリケーションの起動時に SetThreadPrincipal によって設定されたメイン スレッドの ID とは異なることがわかります。

最初の投稿のコード:

サービス インターフェイス:

サービスの実装:

コールバックの実装:

更新サービス構成

UPDATEファクトリ メソッドを使用してサービスを作成します。

PMClientPrincipal は IPrincipal の私の実装であり、PMClientPrincipal.Currentは現在のスレッド プリンシパルを PMClientPrincipal にキャストするだけの静的プロパティです。

UPDATEクライアントのサブスクリプションを管理するクラス (サービスで使用)

コールバック メソッドへのUPDATEコール スタック

WCF サービスでデッドロックの問題が発生しましたが、すべての呼び出しが同じロックで同期されるため、その理由がわかりません。これが私のクライアント/サービス構成です。

binding="netTcpBinding"

サービス構成: ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession、ConcurrencyMode = ConcurrencyMode.Reentrant、UseSynchronizationContext = false)

Callback Config : CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant、UseSynchronizationContext = false)

コード（説明のためにクラス名とメソッド名を簡略化しました）：

コールバックは、別のスレッドで非同期に呼び出されます。クライアントからメソッドを呼び出すDoAction()と、デッドロックが発生し、TimeoutException が発生します。

2015-01-16 10:42:17,463 [8] エラー - (OrderManagerViewModel.cs:311) - CancelOrder : System.TimeoutException: Cette op곡tion de demande envoyꥠ࡮et.tcp://localhost:8002/NetsOrderManagerServiceRemote/ n'a pas re赠de r걯nse dans le dꭡi informi (00:00:05). Le temps allou顠 cette op곡tion fait peut-뵲e partie d'un dꭡi d'attente plus long. Ceci peut 뵲e d fait que le service est toujours en cours de traitement de l'op곡tion ou qu'il n'a pas pu envoyer un message de r걯nse. Envisagez d'augmenter le dꭡi d'attente de l'op곡tion (en diffusant le canal/proxy vers IContextChannel et en dꧩnissant la propri굩 OperationTimeout) et v곩fiez que le service peut se connecter au client.

サーバースタックトレース:
ystem.ServiceModel.Dispatcher.DuplexChannelBinder.SyncDuplexRequest.WaitForReply(TimeSpan timeout)
ystem.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
ystem.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway 、ProxyOperationRuntime 操作、Object[] ins、Object[] outs、TimeSpan タイムアウト)
ࡓystem.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
ࡓystem.ServiceModel. Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime 操作)
ࡓystem.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage メッセージ)

[0] で例外が再スローされました:
ࡓystem.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
ࡓystem.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
ࡎets.Core.API.OrderManager .Service.IOrderManager.CancelOrder(ICancelOrderRequest cancelRequest)
ࡎets.Core.Client.Wcf.OrderServiceWcfClient.RemoteOrderManagerServiceProxy.CancelOrder(ICancelOrderRequest cancelRequest) dans c:\dev\GitProjects\NetsCoreLibProject\NetsCoreLib\Nets.Core.Client.Wcf.OrderServiceWcfClient\RemoteOrderManagerServiceProxy .cs:リーニュ 340
ࡎets.Core.Prototype.Client.ViewModels.OrderManagerViewModels.OrderManagerViewModel.CancelOrder(オブジェクトパラメータ) dans c:\dev\GitProjects\NetsCoreLibProject\NetsCoreLib\Nets.Core.Prototype.Client\ViewModels\OrderManagerViewModels\OrderManagerViewModel.cs:ligne 302

以下のサーバー ログは、DoAction()Callback 実行前に返されることを示しています。

アクション コール ログを行う:

2015-01-16 11:13:57,342 [27] INFO - (RemoteOrderManagerService.cs:195) - CancelOrder : RemoteOrderService : サーバーによって呼び出される CancelOrder アクション 2015-01-16 11:13:57,342 [27] INFO - (RemoteOrderManagerService. cs:203) - CancelOrder : RemoteOrderService : CancelOrder action return report=[CancelOrder report netsd2dce|Failed to validate filter Order Consistency Check 2015-01-16 11:13:57,342 [27] INFO - (RemoteOrderManagerService.cs:208) - CancelOrder : RemoteOrderService : CancelOrder アクション return done

CallbackAfterDoAction コール ログ:

2015-01-16 11:13:57,342 [EventQueue-ThreadDispatcher-HighPriorityEventQueue-2] INFO - (OrderManagerService.cs:451) - DispatchErrorOnOrder: 注文 NetsOrderId[netsd2dce] 2015-01-16 11:13:57,342 でエラーをディスパッチします [ EventQueue-ThreadDispatcher-HighPriorityEventQueue-2] INFO - (Order.cs:760) - OnCancelAck : OnCancelAck[[Order #ob_,ba3 (netsd2dce) BUY 1 [TOTF.PA] @ 47]|所有者=[]]: 実行できませんrequest=[CANCEL] cause Order=[[Order #ob_,ba3 (netsd2dce) BUY 1 [TOTF.PA] @ 47]|Owner=[]] is in final state=[CANCELLED] 2015-01-16 11:13 :57,343 [EventQueue-ThreadDispatcher-HighPriorityEventQueue-2] INFO - (Order.cs:765) - OnCancelAck : OnCancelAck[[Order #ob_,ba3 (netsd2dce) BUY 1 [TOTF.PA] @ 47]|所有者=[]] : Nets.Core.Service.Remote.RemoteOrderManagerService からの呼び出し

BUT: サービスのコールバック呼び出しにコメントすると、DoAction() メソッドが正しく実行されます。デッドロックが発生した場合、DoAction メソッドが戻る前にコールバックが呼び出されたかのように動作します。呼び出されたすべてのメソッドが同じロックで同期されるため、何が起こるかわかりません。

PS:コールバック呼び出しの前にスリープを追加すると:

Sleep(3) までデッドロックは発生しませんが、値が 3 ミリ秒未満の場合はデッドロックが発生します。==> 問題は、ログが反対のことを言っているのに、 DoAction() メソッドの return ステートメントの前にコールバックが処理されるのはなぜですか?

次のサービスとコールバック コントラクト (要約) があります。

サービス契約:

コールバック コントラクト:

サービスの実装:

サービス利用者:

は、およびプロパティSchedulerViewModelを介して、テキスト ボックスとボタンを備えた単純なウィンドウにバインドされます。WCF は、デバッグ用の単純なコンソール アプリによってホストされます。ソリューションは、最初にサービス ホスト (コンソール アプリ) を開始し、次に WCF アプリを開始するように設定されています。StatusStopScheduler

アプリのメイン ウィンドウのボタンをクリックすると、コマンドが呼び出される、つまりproxy.Stop();. これにより、サービスのステータスが変更され、コールバックが呼び出されます。だと思いますが、コールバックがタイムアウトします。デバッガーが行proxy.Stop();でハングし、最終的に次のエラー メッセージが表示されます。

http://localhost:8089/TestService/SchedulerService/に送信されたこの要求操作は 、構成されたタイムアウト (00:00:59.9990000) 内に応答を受信しませんでした。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。これは、サービスがまだ操作を処理中であるか、サービスが応答メッセージを送信できなかったことが原因である可能性があります。(チャネル/プロキシを IContextChannel にキャストし、OperationTimeout プロパティを設定することによって) 操作のタイムアウトを増やすことを検討し、サービスがクライアントに接続できることを確認してください。

コンソール アプリでを使用するSchedulerViewModelと、コールバックが正常に機能し、viewmodelStatus: Stoppedがコンソール ウィンドウに出力されます。他のスレッドを巻き込むとすぐに、コールバックは機能しなくなります。バインドされたテキストボックスを更新するために発生するビューモデルである他のスレッドでありOnPropertyChanged、コマンドの有効化/無効化にさらにスレッドが関与しているかどうかはわかりません。

呼び出されたサービス メソッドでは、最大でミリ秒以上かかることはありません。調査中に同様の問題が発生したため、これはスレッドや UI ハングアップの問題であると信じて正しい方向に向かっていると思います。そのほとんどはまったく異なるシナリオであり、高度な技術的ソリューションでした。

このコールバックを有効にするために、かなり標準的な WPF および WCF インフラストラクチャと関数を使用してできることはありませんか? 私の悲しい代替案は、サービスがステータスをファイルに書き込み、ビュー モデルがファイルを監視することです。汚い回避策はどうですか？

コールバックのある WCF サービスがあります。次に、Callbackfunction を呼び出しますが、それ以外はすべてうまく機能します。次に、リストを渡そうとしますが、コールバックは呼び出されませんが、スローされる例外はありません。他のすべてが正常に機能するため、Callback オブジェクトは機能しています。リスト内のオブジェクトと同じクラス オブジェクトをプッシュすることもできます。Class オブジェクトは として宣言され[DataContract]、Propertiesは として宣言されます[DataMember]。また、リストをループしました。これは通常、Entity Framework によって生成されます。

WCF サービスでコールバックを作成しようとしています。今までのサービスはbasicHttpBindingを使っていたので、netTcpBindingのエンドポイントをもう一つ追加したい。サービスは既に IIS でホストされています。最初は IIS 6 でホストされていましたが、次に IIS 7 をインストールしました。

したがって、次のエラーが表示されます。

要求されたサービス 'net.tcp://localhost:1801/MyServiceName.svc/NetTcpExampleAddress' を有効にできませんでした。詳細については、サーバーの診断トレース ログを参照してください。

ログを見ると、次のメッセージが表示されます。

したがって、主なエラーは次のとおりです。

コントラクトには Duplex が必要ですが、Binding 'BasicHttpBinding' は Duplex をサポートしていないか、Duplex をサポートするように適切に構成されていません。

ここに私の設定ファイルがあります：

サーバーの私のWeb.config :

クライアントの私のApp.config :

IIS の設定:

必要なコードが他にある場合は、お知らせください。質問を更新します。

編集1：

クライアントから (クライアント側で) サービスを呼び出す方法のコードの詳細を次に示します。

ここで、インターフェース (サーバー側) は次のように定義されます。

サービス (サーバー側) は次のように定義されます。

これまでの私の方法は単なるデモです。この質問に関連するエラーが修正されたら、メソッドの開発を開始します。

WCF サービスから Web API アクションへの二重コールバックを受信しようとしています。しかし、どういうわけかこれは機能していません。Web API でコールバックを取得できません。

asp.net コア アプリケーションの代わりにコンソール アプリケーションを使用すると、コンソール アプリケーションはコールバックを受け取ります。したがって、WCF サービスは正しくセットアップされ、正常に動作しています。どういうわけか問題はWeb APIコントローラーにあります（特にコールバックハンドラーに関連しています）

Web API 内にコールバック ハンドラーを記述する方法を提案してください。

これらは私がこれまでに試した手順です-

手順 1: netTcpBinding を使用して WCF サービスを作成する

ステップ 2:この記事で説明されているように、WCF Connected Service 拡張機能を使用して、サービス参照コードを reference.cs という名前のファイルに生成します。

ステップ 3:ツールによって生成された WCF クライアント タイプのインスタンスを作成し、Web サービスと通信するために、Web API コントローラーに以下のコードを記述しました。

私の環境:

Visual Studio 2015 Update3 + WCF Connected Service 拡張機能

netTcpBinding を使用した WCF サービス

ASP.NET コア 1.0 アプリケーション