CODEWITHSUNDEEP
c#asp.net-mvciisnservicebus
cryss
cryss

Reputation: 4499

Handling NServiceBus messages in ASP.NET MVC app

Is it safe to handle NServiceBus messages in ASP.NET MVC application as the application pool can be recycled after some idle time? Let's assume that all the messages should be handled by the handler as soon as possible (it won't be possible after recycling the app pool).

Of course we can disable the idle timeout option, but is it a good practice?

Upvotes: 0

Views: 827

Answers (2)

David Boike
David Boike

Reputation: 18625

It isn't the best idea to handle messages with business value in a web application, because as you mention, keeping the web application alive can be problematic. Any attempt to do so is kind of a hack, so it's generally a better practice to have those messages handled in an endpoint hosted by the NServiceBus Host process.

However, there are a few use cases where it makes a lot of sense for a web application to process messages.

One very common use case is for web applications to subscribe to events to find out when things change. This enables the web application to drop its cache for that item (enabling reload of newly updated data from the web browser on the next request) or even pre-filling the cache with the newly updated data, if that data is contained in the message.

Another great use case would be real-time notifications. In fact, a message handler could respond to those notifications on the server, and then turn around and broadcast them to a browser via AJAX request or SignalR.

In any case, these common use cases will often result in a situation where a web application that is starting up doesn't care about any messages waiting for it in the queue. This is because the handlers would be dropping cache items from an empty cache, or handling notifications well past their useful life.

This is why web applications will commonly use the option to purge the input queue on startup, because those messages aren't useful to a web application just starting up.

Upvotes: 0

Robert
Robert

Reputation: 1069

Particular seems to recommend two options for this kind of IIS application pool behaviour: you can either disable the timeout, or keep the application pool online by sending warmup-request from time to time. This will automatically restart the application pool, so that any messages will be processed as soon as possible.

For more details, look at: http://docs.particular.net/servicepulse/troubleshooting#causes-and-solutions

Upvotes: 1

Related Questions