2

Is there an upper limit to the number of unique IEndpointInstances that be hosted within in a single process?

I'm considering a design that will see up to a 100 unique IEndpointInstances, all listening on separate queues, be active simultaneously.

Will this cause a problem for NServiceBus? Could the process deadlock or spin up so many threads as to be unresponsive and useless?

The question NServiceBus - How to get separate queue for each message type receiver subscribes to? seems to suggest that you can not have multiple endpoints in a process, but this is an older post. I have built a small sample against NServiceBus 6--beta4 that does work.

There is a similar question NServiceBus Single Process, but Multiple Input queues that concluded, based on the OP's context using Satellite Features was the recommended approach. However, in my case, I have 100 (functionally different) sagas (1 per queue), where each saga could need to receive similar messages, but I need to make sure that only the correct saga receives the message. Therefor, I don't think implementing a custom feature will meet my requirements. Or will Satellite Features support Sagas?

Community
  • 1
  • 1
Philip Pittle
  • 11,821
  • 8
  • 59
  • 123

1 Answers1

4

One of the options is to use self multi hosting. Using this approach, you self the endpoints yourself in the same process. There are a few things to take into consideration, such as:

  • Assembly scanning (might require custom scanning logic per endpoint).
  • Throughput (for heavy throughput endpoints I'd recommend a separate hosting process).
  • To update/redeploy a single endpoint, you'll be taking all of the other 99 endpoints down as well.

While there's no hard limit on how many endpoints can be co-hosted, 100 sounds a bit a lot. Saying that, it also depends how heavy the load on those endpoints is. If you process 1 msg/sec or 1K msg/sec determine a lot if this is a viable option or not.

Have a look at the sample that does exactly that.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Re: assembly scanning, was planning on using the `config.excludetypes` method to make sure each saga was the only one handler per endpoint was picked up. Or is there a more efficient way to optimize nsb assembly scanning (still need to look at your links) – Philip Pittle Jul 07 '16 at 07:34