.Net SMTPClient покидает соединение в WAIT_CLOSE

Question

У меня проблема, которая меня пугает. Каждые 2-3 дня я получаю подключения к нашему SMTP-провайдеру, который не заканчивает закрытие. Запуск netstat на сервере показывает соединение со статусом CLOSE_WAIT. Изучая, я думал, что это сузилось, чтобы объект не был утилизирован должным образом.

В частности, класс .Net SMTPClient, который в предыдущей версии фреймворка не реализовал IDisposable. Когда мы перешли в рамки 4.0, нам никогда не приходилось возвращаться и обновлять это, то есть мы были вместе без этих ошибок. Затем несколько недель назад у нас возникла такая проблема. Это началось, когда у нашего провайдера произошел сбой на своих серверах. Теоретически они все еще могут иметь периодические проблемы, которые они не транслируют. Но в любом случае мой код должен восстанавливаться и продолжать работать.

Я прошел через каждый фрагмент кода, который отправляет электронные письма, и все они исправлены. Каждый объект MailMessage и каждый объект SMTPClient находятся в операторе using. Однако я все равно получаю эту проблему случайным образом. Когда это происходит, похоже, происходит несколько раз очень близко друг к другу, а затем не происходит в течение нескольких дней.

Худшая из проблем заключается в том, что, когда я заканчиваю двумя подключениями к одному и тому же серверу с этим состоянием, следующий пул сообщений ждет дополнительного ресурса, но в конечном итоге просто отключается. Сброс службы немедленно устраняет проблему.

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

Answer 1

Вышеупомянутое сообщение было неверным.

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

Я скорректировал разрешенные соединения в файле конфигурации, ожидая, что он просто даст мне больше времени для активного мониторинга проблемы и активного решения проблемы при продолжении поиска решения.

Как только я добавил значение конфигурации, проблема полностью остановилась.

<system.net> 
    <connectionManagement> 
    <add address="{AddressGoesHere}" maxconnection="10" /> 
    </connectionManagement> 
</system.net> 

В самом деле, один из наших меньших используемых услуг, я не сразу применить обновление конфигурации, как она обрабатывается меньше писем и не восприимчив. В конечном счете, этот человек сломался, в то время как более тяжело используемые все еще работали как прелести.

Хотелось бы узнать больше о том, почему. Мое лучшее понимание заключается в том, что мы пытаемся открыть больше подключений к серверу, чем это было разрешено, и это заставляло некоторых зависеть. По умолчанию из 2-х подключений приходилось складывать их, и в некоторых случаях .NET казался таймаутом, пока соединение было открыто, но не отключилось на уровне ОС. (например, 28 секунд ожидания соединения, а затем потребовалось 3 секунды для обработки, но было убито в 30 секунд.)

Теперь, когда я разрешил 10 подключений, они обрабатывают больше потоков одновременно, а не резервное копирование в ожидании слот для открытия. У меня не было проблемы с новой конфигурацией на прошлой неделе.

Я надеюсь, что это может помочь кому-то спать лучше, чем я сделал в течение нескольких ночей :)