Sample with two endpoints in a single host using externally managed mode

1

Is there a sample or example showing how to host multiple endpoints in a single host process when using externally managed DI mode?

2

Hi Geoff!

We have Generic Host multiple endpoint hosting • NServiceBus Samples • Particular Docs that shows how to run multiple endpoints in the same generic host.

While this work it’s usually not worth the added complexity compared to just hosting the endpoints separately, can you share some more details on your requirements?

Cheers,

Andreas

3

Thanks Andreas,

We need to follow the externally managed DI container approach, so the generic host multiple endpoint hosting sample unfortunately does not solve it for us.

We are exploring ways to manage messages with different priorities within the same process, and wanted to see if we can achieve that with multiple endpoints. We’re also interested to hear other ways to achieve that (different priorities).

We are also considering whether we want to have endpoints with different behaviours with regard to idempotency. I.e. for one endpoint we are using an outbox, and we can take advantage of de-duplication to avoid having message handlers need to be idempotent. For some messages we may not need this, so we think they would use a different endpoint.

We have a monolithic application, so hosting endpoints separately does not work for us.

Cheers,
Geoff.

4

We need to follow the externally managed DI container approach, so the generic host multiple endpoint hosting sample unfortunately does not solve it for us.

You should be able to modify the sample to use external mode instead by following

let me know if that would work for you.

We are exploring ways to manage messages with different priorities within the same process, and wanted to see if we can achieve that with multiple endpoints. We’re also interested to hear other ways to achieve that (different priorities).

Using different queues for messages with different priorities is definitely the way to go since that will give you full control over things like scaling, retry policies, etc and also makes monitoring much easier since you know that your high-priority messages are not intermingled with other message types when you monitor various queue/endpoints metrics.

We are also considering whether we want to have endpoints with different behaviours with regard to idempotency. I.e. for one endpoint we are using an outbox, and we can take advantage of de-duplication to avoid having message handlers need to be idempotent. For some messages we may not need this, so we think they would use a different endpoint.

This is also a good example where separate queues and thereby separate endpoints is the way to go since this gives you full control over transaction modes, outbox usage, level of concurrency etc

We have a monolithic application, so hosting endpoints separately does not work for us.

I’m curious what it is that blocks you from hosting endpoints separately. Do you need to communicate in-process with other components? Are there limitations in how you are able to deploy things?

Can you share some more details?

5

Hey Andreas, I work with Geoff.

I’m curious what it is that blocks you from hosting endpoints separately. Do you need to communicate in-process with other components? Are there limitations in how you are able to deploy things?

We are an ISV and would like to keep the installation story for our customers simple for now in that they only need to host a single process.

There are ways we could ask them to host two that might be simple enough, but these would also be a significant change to our processes. It might happen one day, but until we explore the complexity of two endpoints in one process we wont be able to weigh it up with a change to the hosting model for our customers.

6

Thanks for the details @jimmyp , let us know if you have further questions after you have been able to play with the linked sample

Cheers,

Andreas

7

Hey @andreasohlund so far so good, I’ve gotten things working. I have one question though…

We essentially now have 3 subsystems running in a single process, an API and 2 seperate endpoints. When we want to send a message from the API we could grab the message session from either of the 2 endpoints to send it… is there any reason we might prefer one endpoints session over another or it doesnt really matter?

8

The session you use would add audit headers to the message for things like “originating endpoint” so even though it would technically work as long as you are using the same transport for all endpoints I would recommend going with “the right one” to not cause confusion.

Does that make sense?