[
https://issues.apache.org/jira/browse/QPID-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793794#comment-13793794
]
Robbie Gemmell edited comment on QPID-5223 at 10/13/13 9:41 PM:
----------------------------------------------------------------
Setting the system property *qpid.set_expiration_as_ttl* to *true* (i.e.
-Dqpid.set_expiration_as_ttl=true) will cause the 0-8/0-9/0-9-1 client path to
use any non-zero TTL as the direct value of the message 'expiration' header,
rather than the default behaviour of setting it to the computed expiration time
in millis.
was (Author: gemmellr):
Setting the system property *qpid.set_expiration_as_ttl* to true (ie
-Dqpid.set_expiration_as_ttl=true) will cause the 0-8/0-9/0-9-1 client path to
use any non-zero TTL as the direct value of the message 'expiration' header,
rather than the default behaviour of setting it to the computed expiration time
in millis.
> [Java 0-x Client] add system property to set message expiration header as raw
> TTL value for users using 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]
