Страница тайм-аут отправки электронной почты, даже если электронные письма отправляются
Этот вопрос поставил меня в тупик. Этот вопрос, возможно, придется перенести на ошибку сервера, но там есть компонент программирования, поэтому я решил начать с него. Кроме того, наша команда по инфраструктуре горячо верит, что с их стороны все в порядке, но это не всегда что-то значит.
В любом случае, у меня есть простое действие GET-POST-Redirect, которое отправляет два отдельных письма, используя почтовый пакет nuget, перед перенаправлением на страницу успеха-довольно простой материал. Действие асинхронно, и я использованиеawait email.SendAsync() из почтового API.
Когда форма отправлена, первое письмо приходит в мой почтовый ящик мгновенно, но код висит на этой строке await email.SendAsync() в течение хороших 15-20 секунд, прежде чем перейти к следующей строке (подтверждено в отладчике). Затем он переходит к отправке второго письма, которое снова мгновенно попадает в мой почтовый ящик, и снова код висит на этой строке, независимо от успешной отправки, в течение 15-20 секунд, прежде чем перейти к строке с перенаправлением. В производстве, эта задержка после отправки сообщения электронной почты, объединенная для двух сообщений электронной почты, приводит к сбросу соединения до отправки ответа на перенаправление. Конечно, я мог бы просто увеличить тайм-аут страницы, но это на самом деле не решает проблему, поскольку пользователь все равно заканчивает с минутной задержкой, прежде чем получить ответ.
Я также пытался отправлять электронные письма синхронно с just email.Send(), но происходит то же самое поведение. Я просмотрел источник для Postal, и хотя он делает некоторые пользовательские обертки вокруг SMTPClient для отправки асинхронной электронной почты, нет практически ничего, кроме стандартной старой отправки электронной почты C# с синхронным методом Send.
Он также не привязан к серверу, на котором работает сайт, поскольку я могу видеть одинаковое поведение как в рабочей среде, так и при локальной отладке (хотя оба подключаются к одному и тому же рабочему серверу Exchange).
Он ведет себя так, как будто ждет, что сервер Exchange отправит какой-то" готовый " ответ, но из того, что я знаю о SMTP, он так не работает. Он должен просто отправить письмо на SMTP-сервер и продолжать весело двигаться вперед, веря, что SMTP-сервер действительно сделает то, что он должен сделать.
Любые идеи будут высоко оценены, потому что я даже не уверен, как продолжить отладку этого на данном этапе. Что еще я мог проверить или попробовать?
Обновить
Благодаря предложению @MichaelEvanchik опробовать Wireshark, я смог ясно увидеть, что на самом деле задержка составляет 30 секунд вызвано сервером Exchange. Он получает последний бит сообщения электронной почты для отправки, а затем через 30 секунд, наконец, отвечает клиенту с "успешно поставлен в очередь для доставки". Именно в этот момент клиент, наконец, завершает работу и код возобновляется. Итак, я возвращаюсь к инфраструктуре.
Обновление #2
Таким образом, по-видимому, на самом деле была 30-секундная задержка, поставленная на соединитель, чтобы подтвердить, что электронное письмо действительно было отправлено, а не просто поставлено в очередь для доставка. Лично я думаю, что такой вид побеждает точку "очереди на доставку" в первую очередь, но, несмотря на это, мне не нужно подтверждение того, что он на самом деле был отправлен, просто что он был получен сервером Exchange, поэтому инфраструктура устраняет задержку.