在 ASP.NET MVC 应用程序中处理 NServiceBus 消息答案

【问题标题】：Handling NServiceBus messages in ASP.NET MVC app在 ASP.NET MVC 应用程序中处理 NServiceBus 消息
【发布时间】：2015-03-07 06:21:06
【问题描述】：

在 ASP.NET MVC 应用程序中处理 NServiceBus 消息是否安全，因为应用程序池可以在一些空闲时间后回收？我们假设所有的消息都应该尽快被handler处理（回收app pool后就不行了）。

当然我们可以禁用空闲超时选项，但这是一个好习惯吗？

【问题讨论】：

【解决方案1】：

Particular 似乎为这种 IIS 应用程序池行为推荐了两个选项：您可以禁用超时，或者通过不时发送预热请求来保持应用程序池在线。这将自动重启应用程序池，以便尽快处理任何消息。

【讨论】：

是的，我知道消息会在队列中，但是如果 asp.net 应用程序将被禁用（因为 idleTimeout）3 小时呢？然后 3 小时内不会收到消息。我们还假设处理程序应用程序（mvc 或 windows 服务）不会崩溃。
我想我现在明白你的意思了。看看这个页面：docs.particular.net/servicepulse/… 情况并不完全相同，但似乎他们建议要么禁用超时，要么通过不时发送预热请求来保持应用程序池在线。这将自动重启应用程序池。
好的，我明白了，谢谢。你能重写你的评论作为答案吗？然后我会接受它。
谢谢，我已经重写了。

【解决方案2】：

在 Web 应用程序中处理具有业务价值的消息并不是最好的主意，因为正如您所提到的，保持 Web 应用程序处于活动状态可能会有问题。任何这样做的尝试都是一种 hack，因此通常更好的做法是在 NServiceBus Host 进程托管的端点中处理这些消息。

但是，在一些用例中，Web 应用程序处理消息非常有意义。

一个非常常见的用例是 Web 应用程序订阅事件以了解事情何时发生变化。这使 Web 应用程序可以删除其缓存项（允许在下一次请求时从 Web 浏览器重新加载新更新的数据），或者甚至使用新更新的数据预先填充缓存（如果该数据包含在消息中）。

另一个很好的用例是实时通知。事实上，消息处理程序可以响应服务器上的这些通知，然后转身通过 AJAX 请求或 SignalR 将它们广播到浏览器。

无论如何，这些常见用例通常会导致正在启动的 Web 应用程序不关心队列中等待它的任何消息。这是因为处理程序会从空缓存中删除缓存项，或者处理超过其使用寿命的通知。

这就是为什么 Web 应用程序通常会在启动时使用清除输入队列的选项，因为这些消息对于刚启动的 Web 应用程序没有用处。

【讨论】：