[
https://issues.apache.org/jira/browse/QPID-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPID-5223:
---------------------------------
Description:
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.
was:
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.
> [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]
