Как я обрабатываю асинхронные операции в Запуске. Настроить?

В моем ASP.NET 5 приложений я хочу загрузить некоторые данные Azure в кэш в моем Запуске. Настройте метод. Azure SDK выставляет асинхронные методы исключительно. Как правило, вызов асинхронного метода сделан через, ждут в асинхронном методе, как это:

public async Task Configure(IApplicationBuilder app, IMemoryCache cache)
{
    Data dataToCache = await DataSource.LoadDataAsync();
    cache.Set("somekey", dataToCache);

    // remainder of Configure method omitted for clarity
}

Однако ASP.NET 5 требует, чтобы Настраивать метод возвратился пусто. Я мог использовать асинхронный пустой метод, но мое понимание - то, что асинхронные пустые методы, как только предполагается, используются для обработчиков событий (согласно https://msdn.microsoft.com/en-us/magazine/jj991977.aspx среди многих других).

Я думал, что лучший способ сделать это должно будет вызвать асинхронную функцию без, ждут, вызов Ожидают на возвращенной Задаче, затем кэшируют результаты через Задачу. Свойство результатов, как это:

public void Configure(IApplicationBuilder app, IMemoryCache cache)
{
    Task loadDataTask = DataSource.LoadDataAsync();
    loadDataTask.Wait();
    cache.Set("somekey", loadDataTask.Result);

    // remainder of Configure method omitted for clarity
}

Stephen Walther использовал аналогичный подход в сообщении в блоге ранее в этом году. Однако неясно из того сообщения, если это считают приемлемой практикой. Это?

Если это считают приемлемой практикой, что - если кто-либо - обработка ошибок мне нужно? Моим пониманием является та Задача. Ожидайте (), повторно бросит любые исключения, выданные асинхронной операцией, и я не обеспечил механизма для отмены асинхронной операции. Просто называет Задачу. Ожидать () достаточный?

63
задан 2 June 2018 в 03:57

3 ответа

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

Первый, я сказал бы, что, если Вам действительно нужно Configure, чтобы быть асинхронными, затем необходимо поднять вопрос с командой ASP.NET, таким образом, это находится на их радаре. Для них не было бы слишком трудно добавить поддержку ConfigureAsync в этой точке (то есть, перед выпуском).

1117-секундный, у Вас есть несколько подходов к проблеме. Вы могли использование task.Wait (или еще лучше, task.GetAwaiter().GetResult(), который избегает AggregateException обертка, если ошибка действительно происходит). Или, Вы могли кэшироваться задача , а не результат из задачи (который работает, если IMemoryCache больше словаря, чем некоторая странная serialize-into-binary-array-in-memory вещь - я смотрю на Вас, предыдущие версии ASP.NET).

, Если это считают приемлемой практикой, что - если кто-либо - обработка ошибок мне нужно?

Используя GetAwaiter().GetResult() заставил бы исключение (если таковые имеются) распространять из Configure. Я не уверен, как ASP.NET ответил бы, будет то, если конфигурирование отказавшее приложение, все же.

я не обеспечил механизма для отмены асинхронной операции.

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

31
ответ дан 31 October 2019 в 13:00

Можно сделать некоторую асинхронную работу, но метод синхронен, и Вы не можете изменить это. Это означает, что Вы должны синхронно ожидать асинхронных вызовов, которые будут завершены.

Вы не хотите возвращаться из метода Запуска, если запуск еще не закончен, правильно? Ваше решение, кажется, в порядке.

Что касается обработки исключений: Если существует обрабатываемая деталь, без которой Ваше приложение не может работать правильно, необходимо позволить сбою метода Запуска (см. Сбой быстро ). Если бы это не что-то критическое, я включил бы соответствующую часть в блок выгоды попытки и просто зарегистрировал бы проблему для более позднего контроля.

1
ответ дан 31 October 2019 в 13:00

Ответы в здесь не всегда работают правильно, если Ваш асинхронный код выполняет дальнейшие асинхронные вызовы, особенно если это - обратные вызовы, то можно найти мертвые блокировки кода.

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

using Nito.AsyncEx;

AsyncContext.Run(async () => { await myThing.DoAsyncTask(); });
0
ответ дан 31 October 2019 в 13:00

Другие вопросы по тегам:

Похожие вопросы: