Direct Message Propagation Over DMR Mesh

arm
arm Member Posts: 15 ✭
in PubSub+ Event Portal #1

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?

Tagged:

Best Answers

  • ChristianHoltfurth
    ChristianHoltfurth Member, Employee Posts: 75 Solace Employee
    #2 Answer ✓

    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
    ChristianHoltfurth Member, Employee Posts: 75 Solace Employee
    #3 Answer ✓

    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

Answers

  • ChristianHoltfurth
    ChristianHoltfurth Member, Employee Posts: 75 Solace Employee
    #4

    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
    arm Member Posts: 15 ✭
    edited November 2021 #5

    @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
    ChristianHoltfurth Member, Employee Posts: 75 Solace Employee
    #6 Answer ✓

    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
    arm Member Posts: 15 ✭
    edited December 2021 #7

    @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
    ChristianHoltfurth Member, Employee Posts: 75 Solace Employee
    #8 Answer ✓

    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

Categories

This Month's Leaders

This Week's Leaders