問題タブ [pollingduplexhttpbinding]
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.
c# - PollingDuplexHttpBinding とアプリ プールのリサイクル
PollingDuplexHttpBinding
クライアントがアプリケーションでメッセージを交換できるように、を使用します。クライアントはRegisterClient()
、将来の使用のために静的辞書に追加するメソッドを介して登録されます。
コードは次のようになります。
アプリケーション プールがリサイクルされる場合を除いて、すべてが正常に機能します。
もちろん、その点で静的なものは理想的ではないことはわかっています。
アプリ プールのリサイクル後も存続するように、クライアント参照を保存するのに適した場所はどこですか?
c# - Silverlight PollingDuplex クライアント/プロキシを手動で作成するにはどうすればよいですか?
svcutil.exe (または「サービス参照の追加」) の使用がなぜ悪いのかを説明する資料はたくさんあります。テスト容易性の欠如、密結合などです。単純なサービスのクライアント プロキシを手動で作成するのは簡単です。インターフェイスとチャネルを作成します。
同様のことをしたいのですが、Silverlight PollingDuplex クライアント用です。
これはより難しいようです-生成されたクライアントは継承しますSystem.ServiceModel.DuplexClientBase
-手動で作成したクライアントも継承する必要があると思いますか? または、この基本クラスを実装せずに、クライアント側のすべての Duplex コールバック機能を接続する方法はありますか?
誰もこれを試したことがありますか?それは可能ですか?
c# - IIS5.1 で実行しているときに Silverlight PollingDuplex サービスがタイムアウトするのはなぜですか?
IIS7 で正常に動作する PollingDuplex サービス クライアントを備えた Silverlight クライアントを使用しています。コールバック メッセージはクライアント側で問題なく受信されます。ただし、IIS5.1 では同じクライアントとサービスが失敗し、サーバー エラーが発生しますThe IOutputChannel timed out
。5.1 では、サーバーがクライアントにコールバックできないことは明らかですが、なぜでしょうか?
IIS7 と IIS5.1 の両方のテストは、完全にローカル マシン上で実行されます (つまり、クライアントとサーバーの両方がローカルです)。邪魔になるファイアウォールはありません。
アイデアを歓迎します。
silverlight - サービス参照構成の要素 'pollingDuplexHttpBinding' を認識できません
私は、basicHttpBinding と pollingDuplexHttpBinding の 2 つのエンドポイントで WCF を使用しています。Silverlight 4 で WCF を使用しています。basic.. と polling.. だけがあれば、うまくいきます。しかし、1 つのサービスと 1 つの Silverlight プロジェクトで両方を使用すると、クライアント側で次のメッセージが表示されました。
「サービス参照構成の要素 'pollingDuplexHttpBinding' を認識できません。Silverlight では、Windows Communication Foundation 構成機能のサブセットのみを使用できることに注意してください。」
WFC は Silverlight プロジェクトを正しく参照していますが、機能していません。WCF の web.config は次のとおりです。
クライアント側の設定は次のとおりです。
azure - Azure クラウドでのポーリング中にアフィニティからの脱出
Windows Azure で通知を必要とするアプリケーションを構築しようとしています。そのため、Http ポーリングを使用していますが、問題が発生しました。ポーリングを維持できるように、Web ロールのまったく同じインスタンスにアクセスする必要があります。Web ファーム リクエストの書き換え (追加のプロキシ ロールの追加) による解決策を見つけましたが、その解決策は好きではありません。
私の質問です。ステートレス ポーリングを行う方法はありますか。これを実装した人がいる場合は、ヒントまたはリンクを教えてください。
wcf - ポーリング二重 WCF サービスでコールバックのタイムアウトを設定する
CallbackContract を使用した WCF サービスがあります。このサービスは、「pollingDuplexHttpBinding」を使用して Silverlight クライアントに公開されます。Silverlight クライアントが「停止」し、サービスがコールバック操作を呼び出すと、1 分後にタイムアウト例外が発生します。このタイムアウトを別の値に設定するにはどうすればよいですか?
ありがとう、エラド
wcf - 例外:コンテンツタイプapplication / mspd1が、application / soap+msbin1を予期しているサービスに送信されました
WCFサービスとSilverlightクライアントがあります。PollingDuplexElementを使用しています。
サーバー側では、次の構成があります。
クライアントで:
次のエラーが発生します: コンテンツタイプapplication / mspd1が、application / soap+msbin1を予期しているサービスに送信されました。クライアントとサービスのバインディングが一致していない可能性があります。
他に何を構成する必要がありますか。私は多くの時間を費やしましたが、答えを見つけることができませんでした。
wcf - PollingDuplexHttpBindingおよびDuplexChannelFactory-'EndpointDispatcherでのContractFilterの不一致'
Silverlight5クライアントによって使用されるデュプレックスサービスを作成しています。私のサーバー構成は次のようになります(明らかに適切な場所にあります)-
あなたが見る契約はこれです-
これは問題なくホストされているようですが、100%確信はありません。
私のクライアントコードは次のようになります-
'factory.EndConnect(result)'をステップオーバーすると、ContractFilterの不一致の問題が発生しますが、理由がわかりません。明らかにサーバー上で非同期バージョンの同期バージョンを実装しています(つまり、Begin / EndConnectではなくConnectだけです)が、ここで不一致のコントラクトがあると考えることができるのはそれだけです。
私は今本当に髪を抜いています...そして私はすでにハゲです!どんな助けでも本当にありがたいです。
前もって感謝します。
wcf - pollingDuplexHttpBinding を使用してサーバーからクライアントに大きなメッセージを送信する
まず、関連するドキュメントが見つからなかったので、理論を尋ねたいと思います。Silverlight クライアントと WCF サービスがあります。それらの間の通信は、pollingDuplexHttpBinding を介して行われます。サーバーが、設定された MaxBufferSize および MaxReceivedMessageSize よりもサイズが大きいメッセージをクライアントに送信したいとします。その場合、舞台裏で何が起こっているのでしょうか?
さて、これがこの問題に関する私の実際の経験です: サーバー側のバインディング構成:
大きい (つまり、上記のようにクライアントのバインディングのプロパティに設定された値よりも大きい) メッセージをサーバーからクライアントに送信します。次に、2番目の(大きくない)メッセージを送信します=> 2番目のメッセージの送信タイムアウトを取得しました(クライアントが最初のメッセージを受信したかどうかはわかりません)。最初のメッセージで何が起こるかを確認するために、役立つログを検索しようとしました。サーバー側 (WCF ロガーをアクティブ化) とクライアント側 (Fidler を使用) の両方で実行します。ログには特に興味深いものはありませんでした (ただし、正しい場所を検索しなかった可能性があります)。
さらに、sendTimeout が大きな値 (たとえば 10 分) に設定されている場合、サーバーからクライアントに送信されるすべての追加メッセージが「スタック」しているように見えます。クライアントが受信することはなく、送信タイムアウトに達するまで例外はスローされません。さらに、IIS をリセットするまで、クライアントとホスティング IIS アプリケーションによって公開されているサービスとの間の通信が機能しないという奇妙な現象が発生します。これがここで説明した以前の問題に関連しているとは言えませんが、100% 確信はありません。
クライアント側のバインディングで MaxBufferSize および MaxReceivedMessageSize プロパティを設定すると、両方の問題が解決するようです。
このような問題の経験があり、WCF 内の舞台裏で実際に何が起こっているかをここで教えてください。