CODEWITHSUNDEEP
.net-corenservicebusdistributed-system
Rick Neeft
Rick Neeft

Reputation: 145

NServicebus command handlers and multi region

We have an NServiceBus application running in two Azure regions: North Europe and West Europe. We are using SQL transport, and both applications in these regions connect to a shared database. Consequently, both the North and West nodes handles commands from a single endpoint on the same database. This is the desired behaviour as both regions should handle commands

This setup works great until we need to upgrade our software. Upon introducing a new command (and its corresponding handler) and deploy these changes to the a region, we encounter an issue in other regions: no handler can be found for this message type (since we have not upgraded the other region yet). This problem arises because we are running automated tests after each deployment and hold off on further deployments until these tests pass.

We have considered the following options:

Upvotes: 0

Views: 20

Answers (1)

Dennis van der Stelt
Dennis van der Stelt

Reputation: 2178

I'm a developer on the NServiceBus team. I know your company has licenses that warrant quite a few developer support requests per month, so I'd advise to send an email to support at particular.net because then the back and forth is much more convenient and if needed, we can even get on a call.

I'm making some assumptions here, because I'm not sure I understand all the reasons why the "NServiceBus application" is running in two Azure regions. I'm assuming that both applications are the exact same application. As a result, they start competing for messages, hence the name of the pattern: competing consumers. As a result, they both handle the same messages and have the same message handlers.

Once you upgrade an application, you also add new messages and handlers. Since you're talking about only one application, I'm assuming it constantly sends messages to itself. So if the application in RegionA is upgraded and is sending a NEW command called "DoThis" to itself, that's fine. But the same application in RegionB is competing for the same messages. It will also receive the "DoThis" message. But since it's not upgraded yet, it starts receiving this message without having a handler for it.

Luckily NServiceBus doesn't discard the message, but sends it to the error queue. From there you can retry it, preferably using ServicePulse. If you haven't used ServicePulse before, it requires a central component called ServiceControl which reads the error queue and provides an API for ServicePulse so you can retry messages and monitor your system as well.

I hope my assumptions were correct. If not, or you have more questions, don't hesitate to reach out to our support.

Upvotes: 1

Related Questions