2016-12-05 5 views
0

Я использую SendGrid (служба SMTP на основе облачных вычислений) для отправки электронных писем из проекта web api. Я хочу, чтобы мое приложение ожидало/блокировало (например, 30 секунд), пока у меня не будет ответа от SendGrid, прежде чем возвращать ответ клиенту, а не немедленно возвращаться. Библиотека SendGrid имеет метод DeliverAsync, который возвращает задачу.Как подождать по методу async в сторонней библиотеке - web api

Я смотрю, как я могу подождать на задаче.

Я прочитал бесконечные статьи о том, как это можно сделать и понять, что если бы это был мой собственный код, я бы использовал ConfigureAwait (false) для задачи, чтобы предотвратить тупик и позволить мне подождать. Проблема здесь в том, что код не мой! Не похоже, что SendGrid имеет синхронный метод отправки.

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

Надеюсь, это имеет смысл !!

+1

Если вы используете стороннюю библиотеку в Web APi - тогда вы можете использовать 'await', и контроллер вернется только после завершения задачи. – Fabio

+0

Если использовать ключевое слово ожидания в коде не имеет смысла, вы можете добавить «.GetAwaiter(). GetResult();» до конца вызова async SendGrid, и он будет ожидать завершения функции async. – Kyle

+0

В асинхронном методе ASP: NET Web API используется для более эффективного использования потоков. В WPF или Winforms асинхронные методы освободят поток пользовательского интерфейса для другой операции, в то время как Task завершает работу, что делает UI «отзывчивым» с помощью «неблокирующего» потока пользовательского интерфейса. – Fabio

ответ

0

Если вы можете ждать до конца и включать в себя действие контроллера, вам следует, и поскольку это ваш код, он должен быть достижим. В этом случае, самое большее, вы можете рассмотреть ConfigureAwait(true) для вызова только из метода контроллера, а остальные (вниз) - ConfigureAwait(false) (как библиотечные методы должны быть). Большую часть времени вам даже не нужен контекст, сохраненный в действии контроллера - это зависит от того, что вы там делаете - и в этом случае там также используется ConfigureAwait(false).

Вы используете «wait/block», как если бы они были одинаковыми, но в мире TAP они совершенно разные. Использование await будет wait для SendGrid() вызов для завершения перед продолжением, а не блокировка вызывающая нить.

Если вы не можете этого сделать, гораздо менее предпочтительнее использовать блокировку .Wait() или .Result, или, как указывается в других словах GetAwaiter().GetResult(). Все 3 также заблокируют вызывающего абонента. В Web API вы часто можете избежать этого; но в других контекстах - например, WinForms - вы, вероятно, не будете.

Как это ваш код, используйте await.

+0

Спасибо за ответ. Ожидать, что в настоящий момент это не вариант, хотя я понимаю, что это лучшее решение. Я думаю, что все остальные предложения будут заблокированы, потому что сторонняя библиотека не вызывает ConfigureAwait (false) с ее ожидающими вызовами. Итак, я думаю, что это проблема с библиотекой, поэтому свяжитесь с ними для получения дополнительной информации ... – user644698

+0

Если вы не можете ждать, просто сделайте. Результат, но это будет блокирующий вызов. – alltej