У нас есть множество служб WCF, которые работают почти все время, используя различные привязки, порты, максимальные размеры и т. Д. В WCF очень расстраивает то, что когда он (редко) выходит из строя, мы бессильны выяснить, почему не удалось. Иногда вы получите сообщение, которое выглядит так:

System.ServiceModel.CommunicationException: соединение с сокетом было прервано. Это может быть вызвано ошибкой обработки вашего сообщения или превышением тайм-аута приема удаленным хостом, или проблемой основного сетевого ресурса. Тайм-аут локального сокета был «01: 00: 00». ---> System.IO.IOException: невозможно прочитать данные из транспортного соединения: существующее соединение было принудительно закрыто удаленным хостом.

Проблема в том, что тайм-аут локального сокета, который он вам дает, является просто попыткой быть удобной. Это может или не может быть причиной проблемы. Но хорошо, иногда у сетей есть проблемы. Ничего страшного. Мы можем повторить или что-то еще. Но вот огромная проблема. Вдобавок к невозможности сообщить вам, какой именно тайм-аут (если таковой имеется) привел к сбою («превышен тайм-аут приема на стороне сервера» или что-то в этом роде), WCF, похоже, имеет два типа таймаутов.

Тип таймаута № 1) Тайм-аут, который в случае увеличения увеличит вероятность успеха вашей операции. Таким образом, соответствующий тайм-аут составляет час, вы загружаете огромный файл, который займет час и двадцать минут. Это не удается. Вы увеличиваете время ожидания, это успешно. У меня нет проблем с этим типом тайм-аута.

Тип таймаута № 2) Тайм-аут, который просто определяет, как долго вам нужно ждать, чтобы служба фактически перестала работать, и выдает ошибку, но изменение значения этого тайм-аута не влияет на вероятность успеха. По сути, что-то происходит в течение первой секунды запроса на обслуживание, что портит все. Это никогда не восстановится. WCF волшебным образом не повторяет для вас сетевое соединение. Хорошо, иногда установление сетевого соединения не проходит хорошо. Но, если ваше время ожидания составляет 2 часа, вы должныподождать 2 часа без шансов, что он когда-либо сработает, прежде чем он, наконец, признает, что он не работает, и выдает ошибку.

Но ошибка, которую вы видите в обоих случаях, выглядит одинаково. С типом тайм-аута №2 все равно выглядит, что у вас тайм-аут. Но вы можете увеличить все свои тайм-ауты до 4 лет, и все, что нужно сделать, это заставить 4 года получить сообщение об ошибке. Я знаю, что Тип № 2 существует, потому что я могу выполнить операцию, которая, как известно, завершается менее чем за минуту, если она успешна, и для ее завершения требуется 2 часа. Но, если я убью его и попытаюсь повторить, это удастся быстро. (Если вам интересно, почему для операции, которая занимает менее минуты, может потребоваться 2 часа, иногда я запускаю операцию со значительно большим файлом, и это может занять более часа.)

Таким образом, для борьбы с проблемой типа 2 вы бы хотели, чтобы ваш тайм-аут был очень быстрым, чтобы вы сразу знали, есть ли проблема. Тогда вы можете повторить попытку. Но непреодолимая проблема заключается в том, что, поскольку я не знаю, какие таймауты являются причиной сбоя, я не знаю, какие тайм-ауты относятся к типу № 1, а какие к типу № 2. Может быть один тайм-аут (скажем, тайм-аут отправки на стороне клиента), который в некоторых случаях действует как Тип № 1, а в других - Тип № 2. Я понятия не имею, и у меня нет никакого способа узнать.

Кто-нибудь знает, как отследить тайм-ауты типа # 2, чтобы я мог установить для них низкие значения, не сокращая фактические (читай: тип # 1) тайм-ауты и снижая вероятность успеха?

Спасибо.

Разъяснение тайм-аутов типа 2 в ответ на комментарий Эндрю Андерсона:

Я считаю, что что-то идет не так между запросом клиента и кодом, который начинает выполняться на сервере. Во всех случаях, когда у нас есть серверный код, указывающий на частичный прогресс, некоторые операции не завершаются без завершения всего процесса. Таким образом, серверный код никогда не запускается, и то, сколько времени потребуется для его выполнения, не имеет значения (кроме того, что оно влияет на то, на что мы в первую очередь устанавливаем наши значения тайм-аута, чтобы приспособиться к нему).