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

Question

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

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

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

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

Есть идеи?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Думайте об этом так:

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

Answer 4

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

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

Answer 5

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

<dataContractSerializer maxItemsInObjectGraph="2147483646"/>

Answer 6

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

Answer 7

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

Если вы используете LinQ2SQL в своем проекте, откройте файл dbml в Visual Studio и измените режим сериализации на «Однонаправленный» на

Answer 8

Я перехватил то же исключение и обнаружил InnerException: SocketException. в трассировке svclog.

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

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

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

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

Answer 9

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

Answer 10

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