[jira] [Created] (AMQ-5403) remove extra expiration and timestamp manipulaton which will cause problems

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

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)