activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
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
                 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)

Mime
View raw message