Многопоточная служба Windows — проблемы SmtpClient

Мы пишем многопоточный сервис, используя topshelf/windsor/masstransit, чтобы забирать сообщения из MSMQ, а затем отправлять электронное письмо с вложением в формате PDF.

Время от времени метод SmtpClient.Send() выдает это сообщение об ошибке:

Асинхронный вызов уже выполняется. Он должен быть завершен или отменен, прежде чем вы сможете вызвать этот метод.

У меня есть SmtpClient, настроенный как .LifeStyle.Transient в Виндзоре, так что я понимаю, что каждый поток должен получить свой собственный экземпляр?

Любая идея, как я могу обойти это, за исключением блокировки этой части кода. Это как бы противоречит цели потоков.

заранее спасибо


multithreading c# castle-windsor smtpclient
person Albert    schedule 28.02.2011    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Transient следует создавать не просто новый экземпляр для каждого потока, а новый экземпляр для каждого запроса.

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

Если это не удастся, мое единственное предложение - попытаться сократить его до действительно простого примера - если вы не обнаружите проблему при этом, вы можете опубликовать код здесь, и кто-то может помочь.

person Danny Tuppeny    schedule 28.02.2011
comment
Да, переходный процесс всегда дает вам новый экземпляр, без исключений. Трассировка стека и контекст того, что вызывает проблему, были бы хорошими. Сомневаюсь, что это имеет прямое отношение к Виндзору. - person Krzysztof Kozmic; 01.03.2011
comment
Идея GetHashCode очень помогла. В конечном итоге это был класс-владелец (потребитель), экземпляр которого создавался только один раз. Переместил немного кода, и теперь он работает нормально! Спасибо за помощь! - person Albert; 01.03.2011