Once the incoming AMQP message has been converted to a JMS message, there may be some further manipulation performed on the expiration and timestamp in AmqpProtocolConverter:
This was added in
AMQ-5002 as a workaround for a problem in some old message conversation code contributed to 'proton-jms', where the JMSExpiration value was being set to the TTL value from the AMQP message when these actually have different semantics and values. That defect was since resolved via PROTON-474 for inclusion in Proton 0.8. Now that AMQ-5346 is underway, that means we are using the updated proton-jms code and the workaround must be removed otherwise it causes various issues itself:
- It may set a timestamp value where none existed, which could lead to addition of a creation-time field on outbound AMQP messages, whereas the Properties section of the AMQP message is meant to be immutable.
- When setting JMSExpiration to 'new timestamp + old expiration', if the expiration was actually based on the absolute-expiry-time field of the incoming AMQP message then the new JMSExpiration value will be incorrect, much higher than actually requested and preventing the messages from expiring for years longer.