How can you track the topics being routed via DMR Subscriptions between an event mesh?

AllenW
AllenW Member Posts: 13 ✭✭

Trying to get a better understanding of our event mesh which is rather large and uses a lot of DMR subscriptions throughout. As a result - sometimes track the initial source of a message across the mesh can be quite difficult.

I'm trying to find either a CLI command or SEMP query to get a list of DMR subscriptions arriving from a remote broker.


I'm aware of the CLI command:

show message-vpn VPN-A subscriptions

Which outputs all the topic subscriptions for a particular VPN.
However, for tracking topics being transported to other VPNs in the mesh via DMR bridges - this I'm having trouble tracking.

We often see examples like above where messages are being are being published to a non-durable topic, in a VPN (VPN A). In this case there aren't actually any queues subscribing to this. The messages are transports to remote VPNs where only there they are subscribed to by a queue and consumed by a subscriber app. Given this isn't a static bridge, there's is not defined topic subscription as it is done dynamically via DMR. So when trying to map everything out, the publisher is telling us this topic exists in VPN A. But from a Solace side I cannot extract this topic via CLI commands or SEMP API calls - so in the mapping the topic doesn't show up. Only in the remote VPNs (B & C) does this topic show up, as they are subscribed to.

If any of the below options is possible that will solve the issue:
Q1) Is there a way to get a list of non-durable topics in VPN A even if they are not subscribed to?
Q2) Can we see a list of topics in the local VPN (A) which are being propagated across a VPN bridge?
Q3) In the remote VPNs (B & C), is there a way of seeing the topics being recieved via DMR from VPN A?

I'm sure at some point I've come across a command or SEMP query which can do this however have had no luck in trying different ones.

Cheers!

Best Answer

  • RonInglesby
    RonInglesby Member, Employee Posts: 12 Solace Employee
    edited July 4 #2 Answer ✓

    Q2:

    Use: GET <host VPN-A>:<port>/SEMP

    Body: <rpc> <show><smrp><subscriptions></subscriptions> </smrp> </show></rpc>

    I setup a test bed, two connected broker services ron1 and ron2.  ron2 has a queue with a subscription  test/ron
    If I run the above GET on ron1 I can see the subscription in the queue, in ron2, in the result:
    <subscription>
    <vpn-name>ron1</vpn-name>
    <destination-name>g:buiund56jlkprimary</destination-name>
    <destination-type>remote-router</destination-type>
    <persistence>non-persistent</persistence>
    <redundancy>none</redundancy>
    <block-id>0</block-id>
    <dto-priority>DA</dto-priority>
    <topic>test/ron</topic>
    </subscription> (edited) 

Answers

  • RonInglesby
    RonInglesby Member, Employee Posts: 12 Solace Employee
  • RonInglesby
    RonInglesby Member, Employee Posts: 12 Solace Employee
    edited July 4 #4 Answer ✓

    Q2:

    Use: GET <host VPN-A>:<port>/SEMP

    Body: <rpc> <show><smrp><subscriptions></subscriptions> </smrp> </show></rpc>

    I setup a test bed, two connected broker services ron1 and ron2.  ron2 has a queue with a subscription  test/ron
    If I run the above GET on ron1 I can see the subscription in the queue, in ron2, in the result:
    <subscription>
    <vpn-name>ron1</vpn-name>
    <destination-name>g:buiund56jlkprimary</destination-name>
    <destination-type>remote-router</destination-type>
    <persistence>non-persistent</persistence>
    <redundancy>none</redundancy>
    <block-id>0</block-id>
    <dto-priority>DA</dto-priority>
    <topic>test/ron</topic>
    </subscription> (edited) 

  • RonInglesby
    RonInglesby Member, Employee Posts: 12 Solace Employee

    Q3:

    I could not find a SEMP call.

  • AllenW
    AllenW Member Posts: 13 ✭✭

    Thanks so much @RonInglesby, answers for Q1 & Q2 provide everything I need.

    <rpc> <show><smrp><subscriptions></subscriptions> </smrp> </show></rpc>
    

    This is a great help, and solves the issue!

    Thanks again for your help!