X/Y Handlers

[Devindran Ramadass]

My company is tasking me to upgrade NSB from our current v5 to .net core 2 (v7). The current piece I'm upgrading reads from a RabbitMQ queue and there are around 15 handlers in the application that reads different types of messages from that queue.

The problem now is migrating all 15 at one go will be a significant effort for testers to verify and for us to rollback in the event something goes wrong.

Is there a mechanism available where I could leave the existing versions running against the 15 handlers, and have the new .net core version only pick up 3/15 handlers?

[Daniel Marbach]

Hi Devindran,

A step by step migration would work if you isolate handlers one by one into a different endpoint. So basically you'd need a competing consumer endpoint on the same queue that uses v7 and then move handlers over. Although that might also have implications in terms of testing since you introduce a new vector of changes. 

From a risk vector perspective, we can say that v7 is targeting NET 4.5.2 and .NET Standard. The amount of changes we did in v7 are close to zero and were only related to the move to the new target platforms. We are running all our acceptance tests against .NET Framework, .NET Core on Windows and .NET Core on Linux. We are fairly confident that it works ;) So I'd say as long as your handlers are not changing at the same time and you are "only" migrating to new NSB and dependencies you should be fine (famous last words ;) )

Regards

Daniel

[Devindran Ramadass]

I'm probably not explaining this right.

We currently have 1 windows service pointing to endpoint A.B.C. Different payloads (ICommands and IEvents) are being sent to this endpoint from various sources (15 in total).

If I were to push a message of type XYZ to this endpoint from my existing solution, but the NSB7 solution does not have a handler for XYZ, I will get the following error when I start the NSB7 app.

System.InvalidOperationException: No handlers could be found for message type: XYZ

And it will get requeued for processing (going through the delay flow).

Logically I can assume that eventually one of the NSB5 boxes will pick it up and process it correctly, but I'm left with a lot of exceptions in my logs from all the failures attempting to process XYZ by NSB7 which does not have it yet.

Are you saying that this should not be an issue?

Thanks in advance.

[Daniel Marbach]

Hi

The exception you are seeing is expected. When a message is sent to an endpoint that does not have a handler for that message type it goes through the normal recoverability process and eventually moves the message into the error queue. You are right that if you have competing consumers on the same queue that might have a handler there is a chance that the other endpoint with a handler will pick it up and process it. But there is no actual guarantee there so you might be seeing many retries. 

I'm still wondering why you'd want to do that. If you follow our migration procedure for handlers outlined here https://docs.particular.net/nservicebus/upgrades/5to6/handlers-and-sagas#migration the migration should be fairly straightforward from a handler perspective. Therefore it should be possible to move in one go to the new version.

Another option could be to modify the v5 endpoints to send one or two message types that you know you migrated the handler into the new v7 endpoint. But that would mean you'd have to modify the v5 endpoint which again exposes yourself to certain risk vectors. 

I would stick to the upgrade guide and move the endpoint in one go. Or maybe I'm not yet fully understanding the motivation and thoughts behind your proposed migration process.

Regards

Daniel

[Mike Minutillo]

Hi Devindran,

I've just pushed a new sample that might help with your migration. It introduces the concept of a Forwarding Address that can be configured within an endpoint for each message type.

In your scenario you could use this as follows:

Step 1 - move  your existing V5 endpoint to a new address. Do not update the routing of any of your other endpoints. They will continue to send messages to the original address.

Step 2 - create a V7 endpoint with a forwarding address for each of the 15 message types. This will forward all incoming messages to your old endpoint.

Step 3 - for each message type being handled, create a handler in your V7 endpoint for that message type and remove the forwarding address for that message type. New messages of this type will now be handled by the V7 instance only. There may be in-flight messages already in the input queue of your old endpoint that will still be handled there.

Step 4 - once all message handlers have been migrated, you can remove the forwarding address infrastructure from your new V7 endpoint

Step 5 - once the input queue for your old endpoint has been completely drained, you can decommission your original endpoint

At the moment the sample is targeting NServiceBus version 6 but I will be updating it version 7 as well before it is fully released. 

The code and description of the sample are available on github if you want to take a look.

Regards,

Mike Minutillo

Particular Software

[Devindran Ramadass]

Thanks Mike. This gives me some avenue to move towards.

I've been trying to avoid creating a new endpoint as much as possible, but it appears that its the only logical solution. My main problem is that the existing endpoints are all handling Binary serialized messages which v6 onwards no longer supports. So there has to be some form of manual manipulation of the data (via mutators) before its picked up by the handlers. It also means that making v7 as the reader of the original endpoint will require more custom manipulation if  I wanted to be able to send it to the new endpoint for v5 to read (in binary).

I'll see if I can work something out with the ForwardToEndpoint extension you provided. Thanks.

[Daniel Marbach]

Hi Devindran

About the binary serialization. We could solve that root problem and that might simplify things for you. I checked and it seems BinaryFormatter is supported now in the .NET Standard 2.0. I created an unofficial and quick port of the original serializer over here https://github.com/danielmarbach/NServiceBus.BinarySerializer. The master branch contains the v6 version while the develop branch contains the v7 version. Would that help to get you going? That would at least solve the root cause why you are thinking of having multiple endpoints

Regards

Daniel

[Devindran Ramadass]

Thanks all. I think I have what I need to proceed with the migration.