Существующее соединение было принудительно закрыто удаленным хостом - WCF

У меня есть веб-сервис WCF, который работает нормально. Однако есть один конкретный вызов, который терпит неудачу, но только для некоторых пользователей. Вызов довольно прост - это вызов для получения списка объектов Person.

Для пользователя A он отлично работает. Служба запрашивает базу данных, создает список объектов Person и возвращает ее обратно вызывающему приложению.

Для пользователя B он не работает. Странно то, что когда я отлаживаю службу, похоже, все нормально. Он может запрашивать базу данных и создает объект List и возвращает его. Сама услуга никогда не терпит неудачу. Но клиентское приложение получает сообщение "Существующее соединение было принудительно закрыто удаленным хостом".

Мне кажется, что что-то происходит, когда уровень сервиса пытается упаковать данные в формате XML для отправки обратно вызывающему приложению. Я думаю, что это должна быть проблема, связанная с данными, потому что вызов отлично работает для других пользователей. Я визуально просмотрел данные, и я не вижу ничего странного. Можно догадаться, что данные для пользователя B имеют некоторые напуганные скрытые символы или что-то еще, и поэтому вызывает неожиданное закрытие службы. Что-то вроде этого.

Любые идеи?

ОТВЕТЫ

Ответ 1

Лучшее, что я нашел для диагностики таких вещей, это просмотрщик трассировки службы. Это довольно просто настроить (при условии, что вы можете редактировать конфиги):

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

Надеюсь, что это поможет.

Ответ 2

У меня была эта проблема, потому что у моего сайта не было сертификата, связанного с портом SSL. Я думал, что упомянул об этом, потому что я не нашел этот ответ нигде в googleweb, и мне потребовалось несколько часов, чтобы понять это. В средстве просмотра событий ничего не появилось, что было совершенно потрясающе для его диагностики. Надеюсь, это спасет кого-то от боли.

Ответ 3

Я видел это однажды. Являются ли пользователи запрашивают разные объемы данных? Я обнаружил, что даже если вы можете настроить привязку для данных полезной нагрузки (т.е. maxReceivedMessageSize), httpRuntime maxRequestLength превосходит настройку WCF, поэтому, если IIS пытается выполнить запрос, который превышает это, он проявляет такое поведение.

Подумайте об этом так:

Если maxReceivedMessageSize - 12 МБ в вашем поведении WCF, а maxRequestLength - 4 МБ (по умолчанию), выигрывает IIS.

Ответ 4

Я обнаружил, что вы можете получить эту ошибку, если возвращаемый объект имеет только авто-свойства getter, которые инициализируются в конструкторе (с синтаксисом С# 6.0).

Я считаю, что это связано с десериализацией объектов WCF на стороне клиента, используя конструктор без параметров, а затем устанавливающий свойства объекта. Для заполнения объекта необходимо иметь set (он может быть закрытым), иначе он не удастся.

Ответ 5

У меня появилась эта ошибка только на сервере, и решение было установить атрибут maxItemsInObjectGraph в wcf web.config в теге <behavior>:

<dataContractSerializer maxItemsInObjectGraph="2147483646"/>

Ответ 6

Я выбрал одно и то же исключение и нашел InnerException: SocketException. в трассировке svclog.

После просмотра в журнале событий Windows я увидел ошибку, исходящую из класса System.ServiceModel.Activation.TcpWorkerProcess.

Вы размещаете свою службу wcf в IIS с помощью netTcpBinding и совместного использования портов?

Кажется, есть ошибка в функции совместного использования портов IIS, проверьте fix:

Мое решение - разместить вашу службу WCF в службе Windows.

Ответ 7

У меня такая же проблема. Мое решение таково:

Если вы используете LinQ2SQL в своем проекте, откройте свой файл dbml в Visual Studio и измените режим Serialization на "Unidirectional" на

Ответ 8

После того, как вытащили мои волосы за 6 часов этой совершенно бесполезной ошибки, моя проблема закончилась тем, что мой data transfer objects был слишком сложным. Начните с простых простых свойств, таких как public long Id { get; set;}, что он... ничего не представляет.

Ответ 9

У меня была проблема с сериализацией. Причина в том, что некоторые из моих DTO/бизнес-классов и свойств были переименованы или удалены без обновления справочной службы. Я удивлен, что вместо этого я не получил contract filter mismatch error. Но обновление службы ref исправило ошибку для меня (ту же ошибку, что и OP).

Ответ 10

В моем случае это было также с сериализацией. Мне нужно добавить   [KnownType(typeof(...)] для всех классов, которые могут появляться в сериализации.