Thanks for your response, @TomF. You’re right, our consumers are receiving messages thru a subscription, not thru a queue that has a subscription, which explains why the messages are only received by the subscribers online at the time, and never removed from the queue. This probably also explains why messages sent as PERSISTENT by the publisher are received as DIRECT (message demotion?).
So flows are how subscribers can consume messages off of a queue with subscription.
Our queue is an exclusive one, so there can only be one active flow (i.e one active consumer receiving messages via subscription on a queue) at any given time. If an active flow (the first consumer to establish a flow with the queue) were to consume messages off of the queue, then other subscribers won’t get to receive those messages, correct? Even if it weren’t exclusive, our subscribers aren’t the same application, so we would like all of them to receive their own copy of the messages.
How do we then ensure messages are received by all the subscribers (may be online or offline at the time of queueing) before they are removed from the queue?
Without a registry of all the subscribers, it sounds like this may never be possible, but that’s what we’re trying to achieve if possible — all subscribers receive all messages sent by the publisher even if they were offline when they were published/spooled, without the queue disk usage exceeding the maximum spool size. That is why I was wondering if TTL is the only way to achieve something like this. Or, perhaps apps could use their own queue for persistence?