[ 
https://issues.apache.org/jira/browse/PROTON-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890060#comment-13890060
 ] 

Robbie Gemmell commented on PROTON-474:
---------------------------------------

JMSExpiration is annoying. Since the ttl field of the Header is mutable (where 
intermediaries should reduce it) and creation-time is an immutable field of the 
Properties, using creation-time + ttl as may give a JMSExpiration value earlier 
than intended.

For the JMS Mapping currently being worked on in the OASIS AMQP Bindings & 
Mapping TC, the mapping for JMSExpiration is currently such that:
- Clients will set both the absolute-expiry-time (used for the JMSExpiration 
value locally) and ttl fields on outbound messages if TTL is specified for the 
send/producer, so that receiving intermediaries can use which of the fields 
they like.
- Messages arriving at the client map JMSExpiration from the immutable 
absolute-expiry-time if it set, or alternatively use current time + ttl header 
if that is set instead. The latter handles the case where creation-time wasnt 
specified, but also has potential to be fuzzy (this time, later than the 
desired expiration if any intermediaries havent adjusted the ttl header).

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

Reply via email to