Java Client: How to set ttl (seconds) when creating a queue
Hey,
I am trying to find a way of how to set a ttl property in seconds when creating a new queue via jms. Currently I'm using the EndpointProperties which provides only the option to respect the ttl (I guess that can come as a value in headers from the messages). By default when a queue is created and the respect ttl option is set to true, it sets the value of Maximum TTL (sec) to 0. After reading quite of the documentation I can summarize everything in these 2 question:
- Is there a possibility to to set the ttl value in seconds when creating a new queue via jms?
- When setting the respect ttl option and by default Maximum TTL (sec) is set to 0, does that mean that the messages will never expire (even if they have the ttl value set in their headers)?
Comments
-
Hi,
I believe it's not possible to set the max TTL when auto-provisioning queues via JMS (as opposed to creating via Mgmt UI, CLI etc).
However if you set TTL on the message that overrides the queue's default max TTL and messages will expire accordingly.
@TomF will come along shortly and set us straight if I got this wrong ;-)2 -
@swenhelge thank you for the answer
I manage to test this and set the respect ttl to true while creating a new queue. As already mentioned - the default value for ttl in seconds is 0 (and it does seems that when set to 0, the message is never deleted).
Also I can confirm that when a message's ttl is set to some value, it expires. If not set, the message just stays there in the queue.2 -
It sounds like you're on the right track with your investigation into the TTL settings for JMS queues. To address your questions:
- Setting the TTL in seconds when creating a queue via JMS:
Typically, JMS itself doesn’t provide a direct way to set the TTL at the queue level when it's being created. The TTL is usually specified at the message level, often via the producer’s API. If your goal is to enforce a global TTL for all messages in the queue, this would typically be managed by the message broker or JMS provider settings, rather than JMS directly. You might need to configure this within the broker’s configuration (depending on the provider you're using). - TTL behavior when
Maximum TTLis set to 0:
When theMaximum TTL (sec)is set to 0, this usually indicates that there’s no upper limit on the TTL for messages—meaning the messages will not expire as long as their individual TTLs (defined in headers) are respected. However, if therespect ttloption is enabled and a message has a TTL set in its header, that specific TTL will be applied and the message will expire based on that value. If the TTL in the message header is 0 or missing, the message won't expire.
You might want to double-check with your specific JMS provider's documentation to confirm how they handle these configurations.
0 - Setting the TTL in seconds when creating a queue via JMS:
-
Hi there!
It sounds like you're diving deep into JMS configuration! To answer your questions:
- Typically, when creating a new queue via JMS, setting a TTL (Time-to-Live) property directly isn't always straightforward, especially depending on the JMS provider you’re using. You might need to explore whether your provider supports any specific extensions or configurations to set the TTL at the queue level. Also, checking the Java version and its compatibility with your JMS provider might provide more insights.
- Regarding the Maximum TTL being set to 0, that usually indicates that messages won't expire, regardless of the TTL set in the headers. If the respect TTL option is enabled, messages with a TTL set in their headers will still have their expiration enforced, but it’s essential to double-check how your specific JMS provider handles these settings.
I hope this helps! If you have more details about your setup, I might be able to provide further assistance!
0
