Nservicebus: Should we provide some kind of native delayed delivery support for MSMQ

[SzymonPobiega]

So that the core can expect all delayed deliveries are always handled by the transport internally.

[timbussmann]

What's the intended purpose of this issue which can't be handled by Particular/PlatformDevelopment#970 ?

[SzymonPobiega]

@timbussmann you mean 970 PlatDev? The purpose of 970 in PlatDev was to discuss and the decision was made to create an issue in all transport repos to at least consider implementing native delayed delivery of some sort. 970 is now closed as the discussion is over and we want to handle the work to the transport maintainers.

[timbussmann]

to me, this seems like an issue which needs to be handled as a part of the pdev process as this is a non-trivial new feature requiring a proper task-force, communication and more. I'd propose to reraise in pdev and close this issue. @Particular/nservicebus-maintainers thoughts?

[danielmarbach]

I propose we just wait until @SzymonPobiega sends in a spike :trollface:

[SzymonPobiega]

@danielmarbach when you can't go top down, you always can go bottom up ;-)

[timbussmann]

ok as it seems that native delayed delivery mechanism is intended to be implemented on a maintainer budget I think we need to conclude:

• Do we wanna support native delayed delivery for MSMQ if possible?
• If yes: Do some spikes to find a valid approach
• If valid approach found: schedule implementation via milestone

Are there any reasons to not support a native mechanism in general? Can we go ahead and find someone / a task-force interested in doing this or do we wanna backlog this further?

[SzymonPobiega]

@timbussmann Here's a working version of delayed delivery (which is a simplification that assumes delay value is constant): https://github.com/SzymonPobiega/NServiceBus.Raw/tree/master/src/NServiceBus.Raw.DelayedRetries. It can be extended to have multiple queues, one per delay value as @bording proposed.

[danielmarbach]

Given that the majority of our users is using MSMQ but happy with the current approach and MSMQ itself is a technology which has outlived its peak as a transport technology I'm on the fence about investing time into this.

[SzymonPobiega]

Well, if we find somebody who is desperate for using MSMQ without _any_ DB, he can use my bolt-on delayed retries combined with MSMQ subscription store.

[andreasohlund]

With all the other transports moving to native defers perhaps we can just move the current TM + persister combo to be MSMQ only at some point in the future?

.UseTransport<Msmq>().WithTimeoutPersister<NHibernate>()

[timbussmann]

Discussed this with @Particular/nservicebus-maintainers and we agree with @danielmarbach comment that at the current point there is not much value in pursuing a native delay mechanism for MSMQ at the moment.

[SzymonPobiega]

I'd like to question the outcome of this discussion in the light of the spikes I did recently. It turns out WCF has always had a way to specify a custom dead letter queue, per contract. It turned out (via dotPeek) that this is done on a per-message level in MSMQ, via property number 67/68:

message.TimeToBeReceived = TimeSpan.FromDays(1000);
setUI1.Invoke(newProps, new object[] { 7, (byte)1 }); //Enable dead letter
var buffer = StringToBytes(deadLetter);
setString.Invoke(newProps, new object[] { 67, buffer });
setUI4.Invoke(newProps, new object[] { 68, deadLetter.Length });
queue.Send(message, MessageQueueTransactionType.Single);

We the message sent in the way above will come back to the dead letter queue in 1000 days (I verified that for lower values obviously). The only limitation is, the dead letter queue has to be local so you can't have a centralized one (out of the box). That said, we can easily create an endpoint whose only purpose would be receiving messages and putting them in a local centralized timeout queue to wait for their due date.

The amount of effort to implement this seems to be small. I claim the benefit for our customers could be quite impressive given the fact that the would not have to have any persistence if they don't run sagas. It also aligns nicely with the general trend of having native delayed delivery (ASQ, SQL Server, RabbitMQ).

[SzymonPobiega]

Ping @Particular/nservicebus-maintainers

[timbussmann]

very interesting. Let's reopen it and investigate a little bit more about this issue as the effort to use this API doesn't seem to be too large.

[andreasohlund]

Like it, just noting that to make msmq "storage" free we would need to make it use the msmq subscription storage by default

[SzymonPobiega]

Should I escalate it to PlatDev (like this one https://github.com/Particular/PlatformDevelopment/issues/1023) to be prioritized?

[timbussmann]

@SzymonPobiega the feedback I got the last time I asked about pdev was: this can be done via maintainer budget. I'll put this issue on the weekly sync meeting to discuss its priority again. Before the new idea proposed by you, the consensus was that we don't see a high priority in this as the future of msmq doesn't shine very bright at the moment. Let's see whether this is able to change opinions.

[timbussmann]

discussed this again with @Particular/nservicebus-maintainers and personally I feel that we should give at least spend some time for a PoC to check whether this really is a viable solution. It would definitely add value to the MSMQ transport. But from a core maintainer perspective, the msmq "feature" with the highest prio would be to move out msmq from the core, so I'd say let's add this to the future milestone. Thoughts?

[SzymonPobiega]

I volunteer to PoC this. All I need is a green 🚦 from @Particular/nservicebus-maintainers

[andreasohlund]

👍 for a POC

[timbussmann]

@SzymonPobiega @andreasohlund we concluded on yesterdays sync that it this is definitely worth a PoC but from a priority perspective, we should sort out our strategy regarding the MSMQ transport first. E.g. is this valuable enough to do it now and include it in a core minor (is this even a potential breaking change?) or should we move out the transport first? So I'd say let's hold back even with the PoC right now.

[andreasohlund]

I'm with you @timbussmann there isn't enough business value here. Thanks for making me realize that I was just looking at the technical part.

Let's move open an issue for a POC and assign it to the future milestone?

[SzymonPobiega]

OK. I assume this is not a green 🚦 ;-)

[andreasohlund]

Its green to create the issue for the POC :)

[SzymonPobiega]

Naaah, issues are where ideas go to die. I bet if it becomes interesting to the core maintainers you'll find a way to implement this.

[andreasohlund]

Should we create a new NServiceBus.Msmq repo and add it there?

[timbussmann]

@danielmarbach suggested that too yesterday. I'm not entirely convinced as it just moves issues from one repo to another. Not seeing a benefit until we have an actual NServiceBus.Msmq repo which is releasable.

[timbussmann]

raised a new issue for the spike to be scheduled and to close this discussion.