[
https://issues.apache.org/jira/browse/PROTON-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893451#comment-13893451
]
Robbie Gemmell commented on PROTON-474:
---------------------------------------
In this bit of the outbound changes:
{noformat}
+ long now = msg.getJMSTimestamp();
if( msg.getJMSExpiration() != 0 ) {
+ if( now == 0 ) {
+ now = System.currentTimeMillis();
+ }
props.setAbsoluteExpiryTime(new Date(msg.getJMSExpiration()));
+ header.setTtl(new UnsignedInteger((int)(msg.getJMSExpiration() -
now)));
}
{noformat}
Where 'now'=JMSTimestamp, it seems that it could set the ttl larger than it
should be and additionally make it unrelated to the absoluteExpiryTime value
which was just set. Where 'now' = System.currentTimeMillis(), then it seems
possible the calculation could result in a negative, leading to some fun with
later the UnsignedInteger.
> Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
> -------------------------------------------------------------------
>
> Key: PROTON-474
> URL: https://issues.apache.org/jira/browse/PROTON-474
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
> Affects Versions: 0.5
> Reporter: Timothy Bish
> Fix For: 0.7
>
> Attachments: JMSExpiration-patch.txt, PROTON-474-v2.patch
>
>
> The inbound message transformation of AMQP message to JMS message incorrectly
> sets the JMSExpiration to message TTL which is defined in milliseconds while
> the JMSExpiration value is a sum of the Message Timestamp and the producers
> TTL. The transformation should probably map the message creation time + the
> TTL to the setJMSExpiration method.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
