Nservicebus: Make sure that implementing a custom TimeoutManager is possible

[tmasternak]

Context

This is the result of TimeoutManager v6 meeting between @andreasohlund @danielmarbach @SzymonPobiega @timbussmann @Scooletz.

We agreed that we should not be changing TM implementation in V6 (it will be the same as for V5). What we want to make sure though is that currently available extensions points in V6 will enable us to have ability to change TM at the persister level in minor releases of V6.

Goal

The goal of this issue is to create a spike that will prove we are able to freely change Timeouts implementation at the persister level with minor releases of V6. For example we might want to remove any satellites and store timeouts directly in sql tables in case of NHiberante.

One of the approaches proposed was to allow disabling Timeouts feature and register a behavior what will handle message differal.

[danielmarbach]

Ping the squad if you want to get approval

[mauroservienti]

Event if I was not there I'd like to be involved in this, at least at the architectural level.

[andreasohlund]

Since we know, AzureServiceBus proves this, that the tranport can take full control over deferred messaging I'm going to close this one since we can always release a transport that provides a full customized timeoutmanager as a non breaking change.

[SzymonPobiega]

@andreasohlund this was not the point of this issue. The point was to prove that we can build an alternative to the built-in timeout manager _outside of the transport_. The problem is, we can provide a built-in defer capability for SQL Server transport but not for RabbitMQ and MSMQ. If we want to fix it in the minor release by having an external package (say NServiceBus.TimeoutManager) then we can prove we can do it outside of the transport.

[andreasohlund]

if we want to fix it in the minor release by having an external package (say NServiceBus.TimeoutManager) then we can prove we can do it outside of the transport.

Yes it would mean that we would need to release a minor of the transport to allow for it to be plugged in. I'd say that's something we can live with?

install-package NServiceBus.NewPerformantTM

update-package NServiceBus.RabbitMQ

.UseTransport<RabbitMQ>().WithExternalMessageDeferal<PerformantTM>()

where

PerformantTM: IDeferMessages ?

[SzymonPobiega]

:+1: