Then don't set a ttl.
I need a time to live due to the volume of messages, but this is not the only problem. If the client clock is ever faster than the server I will not receive the message since it will appear to the server that my connection is only wants messages from that time forward.
From this link, http://docs.sun.com/source/819-0066/strtbrkr.html
Before starting any brokers or clients, it is important to synchronize the clocks on all hosts that will interact with the Message Queue system. Synchronization is particularly crucial if you are using message expiration (TimeToLive). Timestamps from clocks that are not synchronized could prevent the TimeToLive feature from working as expected and prevent the delivery of messages. Synchronization is also crucial for broker clusters.
For example, server clock is 11:00 AM and the client is 11:05 AM. The client makes the connection. The JMS server sends a message with a timestamp of 11:00. I will not receive that message since my connection is only interested in messages post 11:05 AM timestamp. Is this a correct assumption? It appears to be how the messaging is implemented. Will an infinite ttl allow for these messages to be retrieved?
Yes, clock synchronization is required for the ttl to be valid. At the cost of added overhead the server could act as the central time keeper, but we don't support this.
Setting the ttl to infinite will remove the clock issue.
By setting the ttl to 0, does that mean the topic subscriber will receive all messages that are published to the topic even those messages published before topicsubscriber is created if they have never been acknowledged?
Would this work:
-set ttl to 0
-on application init (when I create the topic subscriber)get server time, drain topic (i.e.acknowledge all messages before that time to get rid of the messages in the messagecache)
-create topic subscriber that will get the messages from that time forward
The only problem that might happen here is a build up of messages if no consumers are attached.
If there is no subscriber there is no buildup of messages.