Is it recommended to have a .NET web application as RabbitMQ producer?
I am asking this because it is not recommended to have a RabbitMQ consumer insider IIS web application : https://stackoverflow.com/a/25571635/2107373
In my case, the ASP.NET web application is hosted on IIS and runs behind a load balancer (multiple instances).
We have a web application that queues messages onto RabbitMQ to be consumed by a different application on the backend and don't experience any issues.
The problems mentioned in the question you refer to are to do with the unreliability of IIS app pool's not always being available to consume messages which shouldn't be an issue if you handle all of the work in creating and queueing a message within the scope of a user's request.
If this is the case then the request is either processed successfuly - a message created and queued and a confirmation response is sent or there is an error - no message is sent and the user is notified by way of a different response.
The biggest challenge we had was handling the possibility of duplicate messages sent - in our case we had a check on the consuming application to make sure the work wasn't done twice and also tied the RabbitMQ producer to the scope of the underlying (sql) database transaction so it was only sent on a successful commit.
There's also a useful answer here as to the advantages of using RabbitMQ as a mechanism to implement backend job processing: Use of messaging like RabbitMQ in web application?
I have something in production that works quite reliably. It only publishes messages so the only concern is managing the connection to the broker. Depending on the volume of messages you don't want to open a connection, publish a single message and then close it.
I used caching to deal with this issue. The connection object (actually an EasyNetQ bus) is cached using a sliding expiration and a CacheItemRemoved callback is registered to close the connection if it hasn't been used within the window lifetime. I also set the priority to CacheItemPriority.NotRemovable as well.
I am not sure how your caching is set up across your web farm so there may be serialization issues. Caching it in-memory on each individual server should work though.
