qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-5223) [Java 0-x Client] add system property to set message expiration header as raw TTL value for users of RabbitMQ
Date Sun, 13 Oct 2013 22:22:42 GMT

    [ https://issues.apache.org/jira/browse/QPID-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793809#comment-13793809

ASF subversion and git services commented on QPID-5223:

Commit 1531761 from [~gemmellr] in branch 'qpid/trunk'
[ https://svn.apache.org/r1531761 ]

QPID-5223: add system property to toggle populating the 'expiration' header with the raw TTL
value instead of the actual expiration time, for interop with e.g. 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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message