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