This article describes your options when migrating your V2.6 time-outs to the new V3.0 format.
If you are not familiar with the NServiceBus time-outs, in brief, NServiceBus supports durable time-outs that survive process restarts. To do that, you need to store the time-outs on disk.
In V2.6 the default storage was an MSMQ queue, but V3.0 uses RavenDB, so you might need to migrate. It may not be necessary because the actual time-out messages sent over the wire are compatible between V2.6 and V3.0.X.
NOTE: The reason to use NServiceBus 3.0.X for the time-out to work is that a bug in V3.0.0 made it incompatible. The bug is fixed in 3.0.X. This means you can run the V2.6 and V3.0.X TimeoutManagers (TM) in parallel until there are no more V2.6 timeouts left, and then decommission the V2.6 TM.
To skip migration and run the TimeoutManagers side by side:
NOTE: This is NOT the same queue as the input queue that you would have configured in your endpoint mappings.
The fact that time-outs are durable means that they could and usually are set to a time very far off in the future. For example, if you have insurance with long cycles you can have your renewal saga set to wake up in X years. In this situation you don't want to run both time-out managers in parallel for that long a time. This is when you would consider doing a migration instead.
To do this we provide a tool in the ZIP download (
/Tools/Migration/TimeoutMigrator.exe) or in the NServiceBus.Tools NuGet package. This tool extracts your V2.6 time-outs and sends them to be managed by the new V3.0 TM.
For those of you who require zero downtime deployments, V18.104.22.1684 doesn't support hot migrations. This means that to migrate your time-outs with your system still running, you need to upgrade to NServiceBus V22.214.171.1241.
With that out of the way, use the tool to migrate:
Command line switches:
Last modified 2014-09-01 08:20:20Z