2

We are trying to get many applications to communicate together and drive actions in each other via NSB. I would like to put each app into its own queue for two reasons: make it easier for support to troubleshoot problems and (possibly) have another place where I could scale the app. The bus will be hosted inside a windows service, possible just single instance that all apps will share. Each app can publish a message that will be picked up by windows service and processed using assemblies from another app, then response message will be put back onto the same queue. Potentially all apps and the window server can be installed on the same machine, and installing many windows services that do the same thing does not sound a like a good answer to me. Is there any way for one windows service hosting NSB to listen to multiple queues?

Thank you.

Sergey Barskiy
  • 1,761
  • 2
  • 15
  • 17
  • NServiceBus enforces one queue to one process. This issue my be a bit similar to yours https://github.com/Particular/NServiceBus/issues/219 – Sean Farmar Oct 31 '13 at 11:42

1 Answers1

2

This is possible using a Satellite, but I wouldn't recommend it for distinct applications. I think you will find that when you start to scale out the applications, you will end up with a 1 to 1 relationship between windows services and queues anyway.

Furthermore it is typical to get even more granular and have 1 message type per queue/service. We have gotten to this point internally with some integrations with third parties. Here is a description of a use case for using a Satellite.

Adam Fyles
  • 6,030
  • 1
  • 23
  • 29
  • Thanks, Adam. The link inside the post is broken, btw. I do understand where you are coming from. It is possible that we will have to got that route in the future. For now, we are going to settle on a single queue, but it will be configurable, so that we can switch to multiple on the fly. I know scalability is important, but installation simplicity for off-the-shelf software is just as important. On top of that, we really do not know what messages we will be sending upfront, those are dynamic as well. Thank you for the feedback. – Sergey Barskiy Oct 31 '13 at 20:17
  • 1
    I thought about it some more, and I think that the restriction of one input (listening) queue per process seems totally arbitrary to me. Personally, I do not not like limitations without a very good reason, and I cannot think of a reason for this specific limitation. – Sergey Barskiy Nov 01 '13 at 12:41