Description
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:
// Lets handle the case where the expiration was set, but the timestamp
// was not set by the client. Lets assign the timestamp now, and adjust
// the expiration.
if (message.getExpiration() != 0) {
if (message.getTimestamp() == 0) {
message.setTimestamp(System.currentTimeMillis());
message.setExpiration(message.getTimestamp() + message.getExpiration());
}
}
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.
Attachments
Attachments
Issue Links
- relates to
-
AMQ-5002 AMQP: If a proton client only sets the ttl, and not the message timestamp, ActiveMQ does not handle the expiration correctly
-
- Resolved
-
-
-
- Closed
-
-
AMQ-5346 Update Proton to version 0.8
-
- Resolved
-