[ 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)