activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <>
Subject [jira] [Created] (AMQ-5403) remove extra expiration and timestamp manipulaton which will cause problems
Date Mon, 20 Oct 2014 12:41:34 GMT
Robbie Gemmell created AMQ-5403:

             Summary: remove extra expiration and timestamp manipulaton which will cause problems
                 Key: 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:

  // 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.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.

This message was sent by Atlassian JIRA

View raw message