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