[
https://issues.apache.org/jira/browse/AMQ-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated AMQ-5403:
--------------------------------
Attachment: 0001-AMQ-5403-remove-old-expiration-workaround-it-is-no-l.patch
Attaching patch to remove the relevant code.
> 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
>
> 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)
