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

["Timothy Bish (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish reassigned AMQ-5403:
---------------------------------

    Assignee: Timothy Bish

> 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
>            Assignee: Timothy Bish
>             Fix For: 5.11.0
>
>         Attachments: 0001-AMQ-5403-remove-old-expiration-workaround-it-is-no-l.patch
>
>
> 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)