У нас есть несколько сервисов WCF, которые работают почти все время, используя различные привязки, порты, максимальные размеры и т. Д. В WCF очень расстраивает то, что когда он (редко) выходит из строя, мы бессильны найти почему это не удалось. Иногда вы получите сообщение, которое выглядит так:
System.ServiceModel.CommunicationException:
Разъем подключения был прерван.
Это может быть вызвано ошибкой
обработка вашего сообщения или получения
тайм-аут превышен пультом
хост или базовая сеть
вопрос ресурса. Тайм-аут локального сокета
был '01: 00: 00 '. --->
System.IO.IOException: невозможно прочитать
данные из транспортного соединения: An
существующее соединение было принудительно
закрыто удаленным хостом.
Проблема в том, что тайм-аут локального сокета, который он вам дает, является просто попыткой быть удобной. Это может или не может быть причиной проблемы. Но хорошо, иногда у сетей есть проблемы. Ничего страшного. Мы можем повторить или что-то еще. Но вот огромная проблема. Вдобавок к невозможности сообщить вам, какой именно тайм-аут (если таковой имеется) привел к сбою («превышен тайм-аут приема на стороне сервера» или что-то в этом роде), WCF, похоже, имеет два типа тайм-аутов. *
Тип времени ожидания # 1) Время ожидания, которое, если его увеличить, увеличит вероятность успеха вашей операции. Таким образом, соответствующий тайм-аут составляет час, вы загружаете огромный файл, который займет час и двадцать минут. Это не удается. Вы увеличиваете время ожидания, это успешно. У меня нет проблем с этим типом тайм-аута.
Тип тайм-аута # 2) Тайм-аут, который просто определяет, как долго вы должны ждать, пока служба действительно выйдет из строя, и выдаст ошибку, но изменив значение этого тайм-аута. не влияет на шанс успеха. По сути, что-то происходит в течение первой секунды запроса на обслуживание, что портит все. Это никогда не восстановится. WCF волшебным образом не повторяет для вас сетевое соединение. Хорошо, иногда установление сетевого соединения не проходит хорошо. Но, если ваш тайм-аут составляет 2 часа, вам придется ждать 2 целых часа без каких-либо шансов, что он когда-либо сработает, прежде чем он, наконец, признает, что он не работает, и выдает ошибку .
Но ошибка, которую вы видите в обоих случаях, выглядит одинаково. С типом тайм-аута №2 все равно выглядит, что у вас тайм-аут. Но вы можете увеличить все свои тайм-ауты до 4 лет, и все, что нужно сделать, это заставить 4 года получить сообщение об ошибке. Я знаю, что Тип № 2 существует, потому что я могу выполнить операцию, которая, как известно, завершается менее чем за минуту, если она успешна, и для ее завершения требуется 2 часа. Но, если я убью его и попытаюсь повторить, это быстро получится. (Если вам интересно, почему для операции, которая занимает менее минуты, может потребоваться 2 часа, иногда я запускаю операцию со значительно большим файлом, и это может занять более часа.)
Итак, для борьбы с проблемой типа 2 вы бы хотели, чтобы время ожидания было очень быстрым, чтобы вы сразу знали, есть ли проблема. Тогда вы можете повторить попытку. Но непреодолимая проблема заключается в том, что, поскольку я не знаю, какие таймауты являются причиной сбоя, я не знаю, какие тайм-ауты относятся к типу № 1, а какие к типу № 2. Может быть один тайм-аут (скажем, тайм-аут отправки на стороне клиента), который в некоторых случаях действует как Тип № 1, а в других - Тип № 2. Я понятия не имею, и у меня нет возможности это выяснить.
Кто-нибудь знает, как отследить тайм-ауты типа # 2, чтобы я мог установить для них низкие значения, не сокращая фактические (читай: тип # 1) тайм-ауты и снижая вероятность успеха?
Спасибо.
Разъяснение времени ожидания типа # 2 в ответ на комментарий Эндрю Андерсона:
Я считаю, что что-то идет не так между запросом клиента и кодом, который начинает выполняться на сервере. Во всех случаях, когда у нас есть серверный код, указывающий на частичный прогресс, некоторые операции не завершаются без завершения всего процесса. Таким образом, серверный код никогда не запускается, и сколько времени потребуется для выполнения, не имеет значения (кроме того, что оно влияет на то, на что мы в первую очередь устанавливаем наши значения тайм-аута, чтобы приспособиться к нему).