Is it safe to call bus.Publish from an NServiceBus handler when using distributor?

135 Views Asked by At

In a scale-out scenario where one server consists of master+worker endpoints and another server consists of workers, is it safe to call bus.Publish from an endpoint when it finishes handling a given event? (Keeping in mind bus.Publish could be invoked from an endpoint sitting on the worker server).

My initial reaction is that it's not safe since it sounds like the example where you should never call publish from a web server...

We could certainly use the WCF wrapper and call out to a service that exists only on the master+worker endpoint server, but does anyone have any practical experience with this?

Thanks!

2

There are 2 best solutions below

0
Dennis van der Stelt On

Each logical subscriber has a receiving endpoint. If you're using the distributor, this is the distributor endpoint, or distributor queue, if you will. So the subscriber will subscribe to specific events and specify it's receiving endpoint. The publisher will have no idea if it's a single endpoint instance, or if it's a distributor receiving the message.

The distributor will then send the message to a worker that is ready to process the message.

This is explained in more detail and with some clarifying images on this page: http://docs.particular.net/nservicebus/scalability-and-ha/distributor/publish-subscribe

0
Thomas Johnson On

In the end, we made our web apps "send-only endpoints" which essentially means they simply send commands directly to an endpoint via a chosen transport (in our case MSMQ). Once we need to scale, we will eventually implement "Sender Side Distribution" rather than utilizing the distributor.

From the NSB support team: "If you add more endpoints, Sender Side Distribution is the way to go. It acts as a round-robin mechanism running on the sender side which would send messages to a different 'worker' endpoint when you scale out."

https://docs.particular.net/transports/msmq/sender-side-distribution

If you only need to fire-and-forget messages from a website or some other app/service, I'd recommend this approach - it's quite simple.