[
https://issues.apache.org/jira/browse/QPID-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPID-5223:
---------------------------------
Summary: [Java 0-x Client] add system property to set message expiration
header as raw TTL value for users of RabbitMQ (was: [Java 0-x Client] add
system property to set message expiration header as raw TTL value for users
using RabbitMQ)
> [Java 0-x Client] add system property to set message expiration header as raw
> TTL value for users of RabbitMQ
> -------------------------------------------------------------------------------------------------------------
>
> Key: QPID-5223
> URL: https://issues.apache.org/jira/browse/QPID-5223
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Minor
> Fix For: 0.25
>
>
> The AMQP 0-8/0-9/0-9-1 specifications leave the behaviour of the message
> 'expiration' field undefined, indicating only that is is a string(?!) value
> for application usage. Qpid's Java broker and AMQP 0-x client have for
> several years used this field to support the JMSExpiration property when ttl
> is >0 by setting the value as <current time in millis + ttl>.
> As per discussion in QPID-5184, when 'per-message-ttl' support was added to
> RabbitMQ in its recent 3.x releases it then began interpreting the message
> 'expiration' header, however treating it instead as a direct TTL value rather
> than the time of expiration.
> Although QPID-5184 resolved the issue seen when using the Qpid client to send
> to RabbitMQ when no TTL has been set (as result of it sending an empty
> expiration string rather than none at all), it does not address a related
> failure that will occur if a TTL actually is set. As RabbitMQ interprets the
> field as a TTL instead of expiration point, the actual expiration value sent
> is too large for RabbitMQ to accept (and wouldn't produce the desired
> behaviour it it was). To enable messages sent to RabbitMQ with TTL to be
> accepted and produce the desired TTL behaviour, the raw TTL value would need
> to be sent instead.
> A system property will be added to enable the client set the expiration
> header as the raw TTL value (for non-zero TTL values) during send()
> operations.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]