How to delay sending out messages in Solace PubSub+
Problem
You do not want Solace PubSub+ to send out your message to the subscribers right away. Instead, you want it to send out the message until a timestamp is reached.
Prerequisite
Download Solace PubSub+ and SDKPerf.
Solution
To let PubSub+ delay sending out messages, follow these steps:
- In PubSub+ Manager, select Queues and then click the green + Queue button.
- In the Create Queue dialog box, type the name of the queue you want to create (queue_b for this example) and click Create.
- In the Edit Queue Settings dialog box, enter queue_a as the DMQ Name and the Maximum TTL (sec) value (3600 for this example).
- Repeat Steps 1-3 to create a new queue called queue_b without the DMQ Name and Maximum TTL (sec).
In SDKPerf, run the command below to set the consuming application to consume from Queue A.
sdkperf_java_d34 -cip tcp://192.168.133.47:55555 -cu solace_cu@solace_vpn -sql=queue_aIn SDKPerf, run the command below to set the publishing application to publish to queue_b with the DMQ eligible flag set.
sdkperf_java_d34 -cip tcp://192.168.133.47:55555 -cu solace_cu@solace_vpn -pql=queue_b -mn=10 -mt=persistent -mdq
Result
When you send the message on to queue_b, it will stay there until the TTL expires. Then Solace PubSub+ will move the message to queue_a and deliver it to your publishing application.
Learn more
Documentation: Setting Dead Message Queues
Comments
-
In many cases, its not practical to set the delay time as the TTL on the queue itself because (a) this same value is applied to all messages (b) the delay you want to apply will depend on when the app publishes the message vs when it should be made available for consumption. So in most cases, the publisher will set the TTL on each message when it is produced as the delta between time the message should be available to consume and the time at which it is published. With the JCSMP API, for example, you can do this with void setTimeToLive(long ttl) on XMLMessage (https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/index.html).
1 -
Hi @Mukund, great question. My personal feeling is that by doing this sort of thing you are bringing business logic into the event distribution layer, which breaks separation of concerns. This is one of the reasons ESBs started to fall out of favour. So I personally would only do this kind of thing as a fix to a problem or if it can't be avoided, say in a legacy integration - I would not want to incorporate it as an architectural practice.
That's just my opinion, though - happy to hear other people's.
1 -
@Mukund and anyone else that comes across this thread, a "Delayed Delivery Queue" is a new feature on the roadmap for an upcoming broker release (maybe even by the end of summer ) so stay tuned and we'll let you know when it's available to try out
6