JmsTemplate ignoring TTL on message level

[cynicLT]

Affects: 5.1.x

---

On sending message to JMS expiration header is ignored by JmsTemplate. TTL may be set per message - Message.setJMSExpiration(long expiration). For now JmsTesmpate support expiration of message per producer - any message level TTL is ignored

	 /**
	 * Actually send the given JMS message.
	 * @param producer the JMS MessageProducer to send with
	 * @param message the JMS Message to send
	 * @throws JMSException if thrown by JMS API methods
	 */
	protected void doSend(MessageProducer producer, Message message) throws JMSException {
		if (this.deliveryDelay >= 0) {
			producer.setDeliveryDelay(this.deliveryDelay);
		}
		if (isExplicitQosEnabled()) {
			producer.send(message, getDeliveryMode(), getPriority(), getTimeToLive());
		}
		else {
			producer.send(message);
		}
	}

Suggestion: resolve TTL of message in following way:

1. TTL per message - if not set then
2. TTL per producer

Current JmsTemplate implementation checks for 2 ignoring message level.

Example of fix:

	 /**
	 * Actually send the given JMS message.
	 * @param producer the JMS MessageProducer to send with
	 * @param message the JMS Message to send
	 * @throws JMSException if thrown by JMS API methods
	 */
	protected void doSend(MessageProducer producer, Message message) throws JMSException {
		if (this.deliveryDelay >= 0) {
			producer.setDeliveryDelay(this.deliveryDelay);
		}
               
                producer.setTimeToLive(resolveTimeToLive(message));

		if (isExplicitQosEnabled()) {
			producer.setDeliveryMode(getDeliveryMode());
			producer.setPriority(getPriority());
		}

		producer.send(message);
	}

	private long resolveTimeToLive(Message message){
       		long messageTimeToLive = message.getJMSExpiration();

		if (messageTimeToLive > 0{
                	return  messageTimeToLive ;
		} else {
                	return  getTimeToLive());
		}
	}

PR could be created and provided.

[petronis]

Had the same issue with it. This would help a lot really strange that you can't set TTL on message level, only on JMSTemplate level.

[kasuparu]

Nicely spotted!

[jhoeller]

Message.setJMSExpiration isn't meant to be used by clients, it's meant to be called internally by the broker when sending a message. With which JMS provider does it work for client purposes?

Quoting its javadoc: "This method is for use by JMS providers only to set this field when a message is sent. This message cannot be used by clients to configure the expiration time of the message."

[jhoeller]

I suppose we could try to detect pre-populated JMSExpiration and also JMSDeliveryMode and JMSPriority and preserve those values, at least in "explicitQosEnabled" mode. In the default mode, we rather won't pass in any explicit settings but leave it entirely up to the JMS provider through calling MessageProducer.send(Message), also not populating Message.setTimeToLive before since that may override the provider's default behavior otherwise. Note that the JMS provider may still internally check Message.getJMSTimeToLive before applying any default of its own, we just don't want to interfere with this.

[cynicLT]

Like this?

 /**
	 * Actually send the given JMS message.
	 * @param producer the JMS MessageProducer to send with
	 * @param message the JMS Message to send
	 * @throws JMSException if thrown by JMS API methods
	 */
	protected void doSend(MessageProducer producer, Message message) throws JMSException {
		if (this.deliveryDelay >= 0) {
			producer.setDeliveryDelay(this.deliveryDelay);
		}
               
		if (isExplicitQosEnabled()) {
			producer.setDeliveryMode(getDeliveryMode());
			producer.setPriority(getPriority());
			producer.setTimeToLive(resolveTimeToLive(message));
		}

		producer.send(message);
	}

	private long resolveTimeToLive(Message message){
       		long messageTimeToLive = message.getJMSExpiration();

		if (messageTimeToLive > 0{
                	return  messageTimeToLive ;
		} else {
                	return  getTimeToLive());
		}
	}

[jhoeller]

Indeed, if we do this it would be along those lines, also covering JMSDeliveryMode and JMSPriority the same way. However, it's still unclear to me whether this is even valid (see my comment above).

[jhoeller]

FWIW, we would preferably keep using the overloaded MessageProducer.send variant with the explicit arguments, making it easier for JMS connection pools to pool the provider (since they'll differentiate by provider settings while being able to reuse a provider instance when only runtime parameters are used).

[cynicLT]

Sure. MessageProducer has explicit API to be called with TTL

[jhoeller]

That API is what we're using in "explicitQosEnabled" already, mostly for the aforementioned provider pooling impact, so we'd simply like to preserve that part.

What I meant is that the only use case for this proposal is user code that pre-populates the message header through Message.setJMSExpiration - which is invalid according to the JMS javadoc. Why else would we have to check Message.getJMSExpiration manually? Same for setJMSDeliveryMode and setJMSPriority, all those methods are meant to be called by the JMS provider, not by user code.

Am I missing something? Is there a specific JMS provider that suggests such pre-populated expiration headers and documents it as officially supported?

[cynicLT]

As example of such work - ActiveMQ implementation of JMS API. It basicly ignores message TTL cause using defaults from MessageProducer API. And it allows to set some very specific headers like delivery mode, priority or TTL.

[jhoeller]

I'm curious about use cases here. So where specifically would you set a time-to-live value at the message level when using it with JmsTemplate? In a MessageCreator? In a MessagePostProcessor? Are you literally just calling Message.setJMSExpiration there before letting JmsTemplate take over? Do these values differentiate per message type or even per individual message?