Direct Message Propagation Over DMR Mesh

arm

How and when are messages propagated from Direct to Non-Persisted when Durable Queue with a matching subscription? Specifically how does this work in a DMR mesh.

Consider the following two scenarios, how and when will messages be propagated and spooled accordingly?

Scenario A: Direct publisher to Node A which has not subscriptions but is DMR meshed with Node B which has a Durable Queue with a matching Topic subscription.

Scenario B: Direct publisher to Node A which has a Durable Queue with a matching Topic subscription and is DMR meshed with Node B which has a Durable Queue with a matching Topic subscription.

Also, what would happen if Node B fails or is unreachable in each of these scenarios? Would the published direct messages be propagated to non-persistent and spooled at Node A until Node B is online or would they be discarded? In Scenario B with Node B down, messages would be propagated and spooled on Node A but would messages also be spooled and delivered to Node B when it comes back online or will messages destined for the durable queues on Node B be discarded on Node A?

ChristianHoltfurth

Hi @arm,
In the scenario you are describing, your JMS messages are basically treated as published as guaranteed on the broker (because: direct = false).

Regarding discards on the DMR link, I believe the broker would increase its discard stats just like with any other client and there would be discard stats on the DMR link as well.

ChristianHoltfurth

Hi @arm ,
DMR links use queues under the cover for persistent messages (you might see some queues starting with #cluster: in your broker). Those queues are set to ignore TTL (per default), so your messages shouldn't expire while they are waiting on a link to be sent over to the next node.

This is similar to how VPN bridges behave, the default is also to ignore TTL.
For VPN bridges however, you can change that setting on the bridge queue.

I believe you can't change this behaviour for DMR links (at least not currently).
The WebUI doesn't allow you to edit the object.

Cheers,
Christian

ChristianHoltfurth

Hi @arm ,

DMR preserves the quality of service for the message as published by your publisher.
So, if your publisher publishes direct messages, they are transported as direct messages over any DMR links and therefore susceptible to be dropped, if the links are over-driven or down.

Promotion (from direct to guaranteed) or demotion (from guaranteed to direct) of QoS happens on the target broker depending on the subscriber QoS.

So in your two scenarios, the outcome would be the same (independent on any local promotion on broker/node A).

If the link between node A and B is down and the messages have been published in direct mode, then the DMR link will drop them when it is down.

If you want to avoid message loss in this scenario, consider changing your publisher to guaranteed.

Best regards,
Christian

arm

@ChristianHoltfurth
Thanks for the quick response. One follow up question, how are messages handled that are published as JMS non-persistent; i.e. Connection Factory setting for send as direct set to false? Would these be persistent on the broker that it was published to then guaranteed from that broker to others with matching subscriptions?

Also, if a DMR link was discarding messages how can this be observed/checked?

Thanks!

ChristianHoltfurth

Hi @arm,
In the scenario you are describing, your JMS messages are basically treated as published as guaranteed on the broker (because: direct = false).

Regarding discards on the DMR link, I believe the broker would increase its discard stats just like with any other client and there would be discard stats on the DMR link as well.

arm

@ChristianHoltfurth follow up question. Could not find in the solace documents about how DMR links handle message expiry. If a neighbor DMR node is down, how will expire of guaranteed messages for that node be dealt with? Is the TTL respected and message discarded if reached or is there the ability to configure a DMR link to not respect message TTL?

Thanks in advance

ChristianHoltfurth

Hi @arm ,
DMR links use queues under the cover for persistent messages (you might see some queues starting with #cluster: in your broker). Those queues are set to ignore TTL (per default), so your messages shouldn't expire while they are waiting on a link to be sent over to the next node.

This is similar to how VPN bridges behave, the default is also to ignore TTL.
For VPN bridges however, you can change that setting on the bridge queue.

I believe you can't change this behaviour for DMR links (at least not currently).
The WebUI doesn't allow you to edit the object.

Cheers,
Christian