If a subscription does not exist for a document, the TTL doesn’t matter. The document will not be delivered anywhere.
If a subscription exists, but the subscriber is disconnected, the TTL determines how long the document will remain active. If the TTL expires before the subscriber retrieves the document, the subscriber will never receive the document. It will be as if the document never existed. It does not matter what the storage type is.
If you need a document to absolutely get to subscribers, set the TTL to forever. Normally, a TTL is applied to request documents in a request/reply interaction and should complement the pubAndWait timeout. If the responder is off-line for a period of time (that exceeds the TTL/timeout) then there is no sense in delivering the request when the responder comes back on-line as there will be noone listening for the response.
A TTL can be set on “normal” pub/sub documents too. This may make sense for time-sensitive data. For instance, say a current price document is published every 15 minutes. Subscribers only care about the latest price. if a subscriber is down and misses one or more of the events it would be meaningless for it to receive the old events.
Use of TTL is common in request/reply operations. Meaningful use of TTL in other scenarios is quite rare.
#Universal-Messaging-Broker#Integration-Server-and-ESB#broker#webMethods