CODEWITHSUNDEEP
azureservicebusmasstransitazure-deployment-slots
kmerkle
kmerkle

Reputation: 58

Mass Transit handles Azure Service Bus messages in secondary deployment slot after swap

We have an implementation of Mass Transit using Azure Service Bus. When deploying the application, we first deploy to a staging deployment slot to warm up the service, then swap the slots to put the staging slot into production. However, messages continue to be handled on the staging slot after the slot swap. As a stop gap, we now shut down the staging slot after the swap. But there is a period of time (~15 minutes) that messages get handled before the slot actually shuts down and we cannot risk the errors that might be generated when the handler logic differs between versions.

Is this a bug in Mass Transit or is there a way to prevent this? I'm not sure what implementation details I need to provide as I inherited the application. I can provide code...

Upvotes: 0

Views: 329

Answers (1)

Chris Patterson
Chris Patterson

Reputation: 33278

It has nothing to do with MassTransit, it has to do with the fact that A/B swapping of services that reach out to backing services (such as Azure Service Bus) do not work well in that scenario.

It's best to disable message-driven services before swapping them out to another slot, or design your services to handle multiple versions running at the same time by ensuring message backward compatibility.

Also, it helps to decouple your message consuming services from your front-end API services (which are more commonly swapped live, versus upgraded).

Upvotes: 2

Related Questions