Nservicebus: Msmq enlists outgoing operations in receive transaction when TransportTransactionMode.ReceiveOnly is specified

[andreasohlund]

Right now we ignore it and enlist as long as None isn't used. This is only a v6 problem since v5 didn't have this receive only mode

Who's affected

MSMQ users on V6 requesting the receive only mode.

Symptoms

1. When you issue a bus.Send inside a handler the operation will not be immediately dispatched but batched and then dispatched later.
2. Since there is a bug in MSMQ that which will not allow you to use TimeToBeReceived together with transactions the operation will blow up since you cannot use TTBR with transactions.

[danielmarbach]

Based on the triaged together with @andreasohlund @tmasternak @timbussmann we came to the conclusion that this low impact and doesn't have to be done as part of project V6.

[ramonsmits]

For #4161 I tested immediate dispatch but at the same time also did a performance tests on a scenario where for each message received a single message is send.

These are the averages of 3 runs:

• ReceiveOnly default send : 4,859 msg/s
• ReceiveOnly immediate dispatch : 6,018 msg/s

This gives an idea of a possible performance gain too if not having batched sends and sends not using the receive transaction on MSMQ.

[andreasohlund]

Rereading this I think the workaround I proposed is wrong since RequireImmediateDispatch will send the messages straight out so we loose the atomicity btw business data and outgoing ops?

[ramonsmits]

@andreasohlund Yes, if the user is running with TransactionScope or SendsAtomicWithReceive.

This is a perfectly good option when running with ReceiveOnly as that would be expected but currently not working due to the transaction in the batching.

[danielmarbach]

Let's agreee first that we don't have to fix this for RtM. we could,
introduce express on top of extandable option (make it a publish/send
concern) and then dispatcher can sort against that delivery constraint and
dispatch accordingly. Deprecate express attribute with warn. Introduce
header when TTBR is not supported by transport and modify the pump with
noop receives (benefit those msgs will not end in DLQ). Would need to check
with backward compat though

[ramonsmits]

No it' s not critical at all and not a requirement for RTM.

[andreasohlund]

Removed the workaround to use ImmediateDispatch after talking to @ramonsmits since it would lead to ghost messages

https://docs.particular.net/nservicebus/messaging/batched-dispatch

and that isn't a good workaround since it fundamentally changes the consistency guarantee

[timbussmann]

Removed the workaround to use ImmediateDispatch after talking to @ramonsmits since it would lead to ghost messages

isn't TransportTransactionMode.ReceiveOnly implying that ghost messages can happen? What kind of consistency guarantees do we give for outgoing messages?

[andreasohlund]

isn't TransportTransactionMode.ReceiveOnly implying that ghost messages can happen?

ReceiveOnly can lead to ghost messages (even though batched dispatch makes is much less likely compared to v5). With outbox on we eliminate this since we store business data and outgoing ops in a single atomic storage transaction.

So perhaps we can put the workaround back in stated like

If you're not using the outbox ImmedidateDispatch can be used as a workaround. Note that this workaround will increase the likelihood of ghost messages being emitted?

What kind of consistency guarantees do we give for outgoing messages?

We don't guarantee anything if in ReceiveOnly mode

[timbussmann]

I think we should avoid the term "ghost messages". Maybe just state that an immediate dispatch message cannot be rolled back?

[tmasternak]

I think we should avoid the term "ghost messages"

Why? I'm not sure it's a well know terminology but follows the analogy to db isolation levels and possible anomalies like non-repeatable reads or phantom reads. I think it's good to talk about anomalies that can occur in given transaction mode/configuration.

[timbussmann]

I'm not sure it's a well know terminology but follows the analogy to db isolation levels and possible anomalies like non-repeatable reads or phantom reads.

googling "phantom reads" brings a proper explanation as the first result in google and it's a well known terminology as you described.
Googling "ghost messages" doesn't yield any immediately useful results for me and I wouldn't it consider it an established vocabulary across messaging products (and I don't see any clear relation between phantom reads and ghost messages, but not sure whether you wanted to indicate any similarities?).

I think it's good to talk about anomalies that can occur in given transaction mode/configuration.

fully agree 👍 just stating that we should not assume everyone is familiar with our terminology which we explain nowhere.