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?

[cynicLT]

We do it per message in MessageCreator based on message type by calling setJMSExpiration

[jhoeller]

After some further research, I still haven't found any indication that such a user-level Message.setJMSExpiration call is valid. Even in ActiveMQ forums, I saw the recommendation to always use producer-level settings since message-level settings will get overwritten by the broker.

ActiveMQ does not seem to respect a Message.setJMSExpiration setting when passing the resulting message to plain MessageProducer.send(Message), so this isn't something to adapt to in our "explicitQosEnabled" mode either. It looks like we'd have to manually handle those headers in both modes, as per the original code suggestion above, but that seems wrong in that it would bake a non-idiomatic pattern into our JmsTemplate... a pattern that would not work with plain JMS at all.

This issue title makes it sound like a JmsTemplate-specific deficiency while it actually is a JMS-wide convention that such message-level TTL headers are being ignored when set by the user. Are you asking us to circumvent that rule as a JmsTemplate-specific feature? Am I missing something?

[cynicLT]

Yes - as a JmsTemplate feature. It is widely used to communicate with JMS thus adopting such behavior would be friendly for framework users. It could be enabled per configuration. In later releases it could be removed as Brokers would introduce such behavior ( as it is in RabbitMQ)

[snicoll]

While I agree that part of the spec/api is confusing and has tripped numerous users,
I don’t think we should do that.

The javadoc is very specific and I am not keen to ignore it. It would also be weird that JmsTemplate would do something that all other compliant JMS clients wouldn’t.

[cynicLT]

@snicoll does it mean that JmsTemplate should rely on send(Message) method and broker would handle priority TTL and other features based on message? Current implementation not following such approach.

[snicoll]

The TL;DR is that Message.setJMSExpiration is not meant to be called by users, per spec and per javadoc so we shouldn't be doing that. If you need to set the expiration, you need to call the dedicated send method that takes a timeToLive. With JmsTemplate that happens with QosSettings: when that's set, JmsTemplate calls that specific send method which is what you should be doing.

[cynicLT]

So there is now way with Spring set TTL per message only per template? In other case should integrate with JMS broker bypassing Spring?

[snicoll]

I think we're running a little bit in circles here. We've already answered this question in a number of different ways. I don't think bypassing Spring is going to give you much as you'd have to call the send specific method and the expiration time is not read from the Message there either.

I understand you'd like us to do something about it but unfortunately we can't as the spec is very clear on that front.

[jhoeller]

From my perspective, I would only really revisit our arrangement in JmsTemplate if such message-level TTL settings work with regular JMS but not with JmsTemplate.

Since regular JMS MessageProducer.send(Message) seems to ignore any such user-set headers on the message as well, even on ActiveMQ, we seem to be in line with not only the JMS spec but also common runtime behavior in actual JMS brokers. In that sense, JmsTemplate ignoring TTL at the message level is by design, for alignment with regular JMS. Otherwise somebody could create a bug report and claim that we mis-respect JMS headers that need to be ignored as per the JMS spec...