NServiceBus 5 publish and listen to multiple queues and use priority queues with RabbitMQ

0
votes

I'm using NServiceBus 5 with RabbitMQ as transport protocol. In RabbitMQ I have the option to bind more than one queue to an Exchange, and set priority queue.

I would like to do the same with NServiceBus but don't know if it's possible and how. Is that sort of thing supported by NServiceBus?

1
rabbitmqnservicebus
Can you share some more details on your specific use case? (We do have a few extension points that you might be able to leverage) - Andreas Öhlund
@AndreasÖhlund hey. I have a worker that handles most of the aspects in my system. it currently listens to one queue, and sometimes it's very busy. There are messages that if coming in, we would like to take care of immediately, and not let them wait in queue until other messages are finished handling. So what we would like to do is put the "priority" messages in a different queue and have them handled before all other in "regular" queue. - developer82
@developer82, can you tell us how you solved the issue? (I'm looking especially after how to perform priority queue). thanks - Tomer Yoskovich
@Jackl56 In my production code we eventually didn't use multiple queues to do priority - instead we used the NSB way and broke it to services. But before we did, what I managed to do is to download the NServiceBus RabbitMQ Transport library and recompile with another consumer. I wrote some additional code that looks for "extra" consumer settings and sets it up accordingly. - developer82
@developer82 thanks for the followup. I didn't understand what you mean by "... the NSB way and broke it to services" and "...recompile RabbitMQ NSB transport library with another consumer". could you please further clarify it? thanks - Tomer Yoskovich

1 Answers

0
votes

There is currently no support for RabbitMQ endpoints receiving from more than one queue. Our guideline is to split those important message to a separate endpoint (queue). This will give you the following benefits:

  • Updates to the business logic of the other messages would not require you to stop processing the important messages
  • You can tweak the concurrency/message throughput to optimize for the important messages
  • You can define a retry policy optimized for the important messages
  • You can scale out that endpoint separately if needed
  • You can setup better monitoring/alerts given that you know what messages the endpoint is processing
  • Performance metrics like Critical Time etc will be more accurate since it will only monitor the important messages