5

Let's say that I want to consume AMQP messages from ASP.net MVC 4 using RabbitMQ. I store an object in System.Web.HttpContext.Current.Application which internally uses an instance of BackgroundWorker to listen for messages (the listener is created in Global.asax.cs)

Is this a good way to implement this operation or should I use a static class / singleton? I am inexperienced in ASP.net MVC so I am uncertain. Maybe ASP.net MVC 4 is not the best platform choose? What would you recommend?

The goal is to be able to monitor/log message traffic, kill/create/configure consumers at will from a web interface.

This is my first stackoverflow post as I believe in good research. But, this time I would like to hear from other people, thx :)

Jean
  • 7,623
  • 6
  • 43
  • 58
user2140283
  • 86
  • 1
  • 7
  • Similar post is [here](http://stackoverflow.com/questions/9693732/asp-net-4-0-background-worker-best-practice) It contains [this](http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx) link – user2140283 Mar 07 '13 at 08:21

1 Answers1

4

An ASP.NET application makes a poor RabbitMQ subscriber in my opinion. You are far better off implementing your subscriber as a windows service.

  1. This excellent post by Phil Haack gives some good reasons why should think twice about using the BackgroundWorker for any serious service.
  2. It means that you can monitor and maintain your subscriber independently of your web application. You can use all the out-of-the-box tools that windows gives you - task monitor, perf monitor - to understand how your service is behaving.
  3. You can scale your subscriber independently of your web application. You might need only one instance of your web application, but two of your subscriber. Having them as separate processes gives you that kind of finer grained control.
Justin Rusbatch
  • 3,992
  • 2
  • 25
  • 43
Mike Hadlow
  • 9,427
  • 4
  • 45
  • 37