Безопасно ли обрабатывать сообщения NServiceBus в приложении ASP.NET MVC, поскольку пул приложений может быть повторно использован после некоторого простоя? Предположим, что все сообщения должны обрабатываться обработчиком как можно скорее (это будет невозможно после утилизации пула приложений).Обработка сообщений NServiceBus в приложении ASP.NET MVC
Конечно, мы можем отключить опцию простоя, но это хорошая практика?
В частности, рекомендуется рекомендовать два варианта такого поведения пула приложений IIS: вы можете отключить таймаут или сохранить пул приложений в сети, время от времени отправляя запрос на разминку. Это автоматически перезапустит пул приложений, так что любые сообщения будут обработаны как можно скорее.
Для получения более подробной информации, смотрите по адресу: http://docs.particular.net/servicepulse/troubleshooting#causes-and-solutions
Это не лучшая идея для обработки сообщений с бизнес-ценность в веб-приложении, потому что, как вы говорите, сохраняя веб-приложение в живых может быть проблематичным. Любая попытка сделать это - это взломать, поэтому обычно лучше использовать эти сообщения в конечной точке, размещенной в процессе NServiceBus Host.
Однако есть несколько вариантов использования, когда веб-приложение имеет большой смысл обрабатывать сообщения.
Один очень распространенный вариант использования веб-приложений для подписки на события, чтобы узнать, когда все изменится. Это позволяет веб-приложению отбрасывать свой кеш для этого элемента (разрешая перезагрузку недавно обновленных данных из веб-браузера при следующем запросе) или даже предварительно заполняя кеш обновленными данными, если эти данные содержатся в сообщении.
Другим замечательным вариантом использования могут быть уведомления в режиме реального времени. Фактически, обработчик сообщений мог реагировать на эти уведомления на сервере, а затем поворачиваться и транслировать их в браузер через запрос AJAX или SignalR.
В любом случае эти общие случаи использования часто приводят к ситуации, когда запускается веб-приложение, не заботятся о каких-либо сообщениях, ожидающих его в очереди. Это связано с тем, что обработчики будут отбрасывать элементы кеша из пустого кеша или обрабатывать уведомления задолго до их полезного срока службы.
Именно поэтому веб-приложения обычно используют опцию для очистки входной очереди при запуске, потому что эти сообщения не приносят пользы только для запуска веб-приложения.
Да, я знаю, что сообщения будут в очереди, но что, если приложение asp.net будет отключено (из-за idleTimeout) в течение 3 часов? Затем сообщения не будут получены в течение 3 часов. Предположим также, что приложение обработчика (mvc или служба Windows) не будет аварийно завершено. – cryss
Думаю, я понимаю, что вы имеете в виду сейчас. Взгляните на эту страницу: http://docs.particular.net/servicepulse/troubleshooting#asp-net-applications-heartbeat-failure Это не совсем такая же ситуация, но похоже, что они рекомендуют либо отключить таймаут или сохранить пул приложений в сети, время от времени отправляя запрос на разминку. Это автоматически перезапустит пул приложений. – Robert
Хорошо, я вижу, спасибо. Не могли бы вы переписать свой комментарий в качестве ответа? Я тогда приму это. – cryss