Durable queues w/ MT 2.9.9

[Aaron Vance]

First, I understand I am using a legacy version of MT.

We have a dependency on MSMQ which prevents us from transitioning to using RabbitMQ at this time.

We are using the mass transit runtime services/subscription manager.

That said, I'm trying to setup a publisher/consumer scenario where messages are not lost if a consumer is unavailable.

I've scanned this forum and stackoverflow and the primary take-away I'm finding about durable queues is to never call the unsubscribe action.

I am not calling unsubscribe action delegate explicitly.

I do see the subscription clients and sagas stick around in the mass transit SQL store holding the subscriptions. (thus, they are durable, in my mind, because when I do call the unsubscribe action, the SQL store gets cleaned up once publisher/consumer are offline).  But I am explicitly not calling the unsubscribe delegate in the scenario I will describe.

Here's what I'm observing, and would like to understand if something is not working, or the expected behavior.

1. Publisher A comes online and starts spitting out events via .Publish()

2. Consumer B comes online and starts collecting events - but only those published after it is online. (Expected)

3. Publisher A finds Consumer B via subscription manager, and B starts consuming.  B also fires a response back to A, and A concurs. (Expected)

4. Consumer B is taken offline.

5. Publisher A continues to spit out .Publish(msg) calls - they start to accumulate in the Consumer B queue.  As expected.

6. Later, Consumer B comes online, and consumes messages. Expected.

Next with A and B running.

1. Stop Publisher A. Stop consumer B.

2. Look in subscription manager SQL - subs/sagas are still there.

3. Start Publisher A.  Don't start Consumer B.

4. No messages queue up for B to collect.

Why is B not receiving messages in its queue when A is publishing, and subscription manager "knows" about the Consumer B's subscription?

Alternatively, when I use .Send() instead of .Publish() off the endpoint, it does accumulate, obviously because we're directing messages directly to B's queue via .Send().

Am I wrong to expect that published events via .Publish() should also retain durability in the queue even when the consumer is offline?  Or is it an MT opinion that events are pub/sub, and events may or may not be consumed?

Thank you, Aaron