Robbie Gemmell created AMQ-5403:
-----------------------------------
Summary: remove extra expiration and timestamp manipulaton which
will cause problems
Key: AMQ-5403
URL: https://issues.apache.org/jira/browse/AMQ-5403
Project: ActiveMQ
Issue Type: Bug
Components: AMQP
Reporter: Robbie Gemmell
Fix For: 5.11.0
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:
{noformat}
// 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());
}
}
{noformat}
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
