既存の接続がリモートホストによって強制的に閉じられました - WCF

Question

正常に動作しているWCF Webサービスがあります。しかし、失敗している特定の呼び出しがありますが、特定のユーザーだけが失敗します。この呼び出しはかなりシンプルです。これは、Personオブジェクトのリストを取得するための呼び出しです。

ユーザーAにとっては問題ありません。サービスはデータベースに照会し、Personオブジェクトのリストを作成し、呼び出し元のアプリケーションに戻します。

ユーザーBの場合は失敗します。奇妙なことは、私がデバッグすると、サービスは正常に動作しているようです。データベースに問い合わせることができ、Listオブジェクトを作成して返します。サービス自体は決して失敗しません。しかし、クライアントアプリケーションは、 "既存の接続はリモートホストによって強制的に閉じられました"というエラーを受け取ります。

私には、サービス層がXML形式のデータをパッケージ化して呼び出し元のアプリケーションに送り返そうとしているときに、何かが起きているようです。私は、コールが他のユーザにとってうまく働くので、データに関連する問題でなければならないと考えています。私は視覚的にデータを見て、私は奇妙なものは実際には見ません。 1つの推測では、ユーザーBのデータにはファンキーな隠れた文字などがあるため、サービスが予期せず終了する原因となります。そんな感じ。

アイデア？

Answer 1

このようなことを診断するために私が見つけた最良のものは、サービストレースビューアです。それは（あなたがコンフィグを編集することができます仮定）を設定する非常に簡単です：

http://msdn.microsoft.com/en-us/library/ms732023.aspx

は、この情報がお役に立てば幸いです。

Answer 2

私はこれを一度見ました。ユーザーが異なる量のデータを要求していますか？データペイロード（つまりmaxReceivedMessageSize）のバインディングを設定できる場合でも、httpRuntimemaxRequestLengthはWCF設定よりも優先されるため、IISがそれを超える要求を処理しようとすると、この動作を示します。このようなことの

考える：maxReceivedMessageSizeは、あなたのWCFの行動の12メガバイトで、maxRequestLength

場合は、4メガバイト（デフォルト）で、IISが勝利します。

Answer 3

ウェブサイトにSSLポートにバインドされた証明書がないため、この問題が発生しました。私はgooglewebのどこでもこの答えを見つけられなかったので、私はそれを言及すると思った、そしてそれを理解する時間がかかりました。イベントビューアには何も表示されませんでしたが、それは診断にとって非常に素晴らしいものでした。これは誰か他の誰かを救うことを望む。

Answer 4

私は唯一のサーバーになりました。このエラーが発生しましたし、溶液がmaxItemsInObjectGraph WCFのweb.configファイル内の属性 <behavior>下のタグを設定することでした：

<dataContractSerializer maxItemsInObjectGraph="2147483646"/> 

Answer 5

を私は、同じ例外をcatchedとでInnerException: SocketException.を発見しましたsvclogトレース

Windowsイベントログを調べた後、私はSystem.ServiceModel.Activation.TcpWorkerProcessクラスからのエラーを見ました。

netTcpBindingとポート共有を使用してIISでwcfサービスをホストしていますか？

fixを確認し、IISポート共有機能にバグがあるようです。

私のソリューションは、WindowsサービスであなたのWCFサービスをホストすることです。

Answer 6

私は同じ問題を抱えています。完全に役に立たないプロジェクトでLinQ2SQLを使用している場合

は、Visual StudioであなたのDBMLファイルを開き、次の6のような時間のために私の髪を引っ張った後

Answer 7

上に「単方向」シリアル化モードを変更します。私の解決策はこれですエラー、私の問題は、私のdata transfer objectsが複雑すぎるということに終わった。 public long Id { get; set;}のようなuberの単純なプロパティから始めましょう。

Answer 8

私が持っていた問題は、シリアル化でもありました。その原因は私のDTO /ビジネスクラスの一部であり、サービス参照を更新せずにプロパティの名前を変更または削除しました。私は代わりにcontract filter mismatch errorを得られなかったことに驚いています。しかし、サービスrefを更新すると、私のエラーが修正されました（OPと同じエラー）。

Answer 9

私の場合は、シリアル化されていました。シリアライゼーションに表示される可能性があるすべてのクラスに対して、 [KnownType(typeof(...)]を追加する必要があります。

Answer 10

返されたオブジェクトに、コンストラクタ（C＃6.0構文）で初期化されたゲッターのみの自動プロパティがある場合、このエラーが発生することがあります。

これは、パラメータのないコンストラクタを使用してオブジェクトのプロパティを設定することで、クライアントサイドでオブジェクトを逆シリアル化するWCFが原因であると考えられます。 setが利用可能である必要があります。（それはプライベートにすることもできます）オブジェクトを埋める必要があります。それ以外の場合は失敗します。