[
https://issues.apache.org/jira/browse/QPID-8405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024244#comment-17024244
]
Robert Godfrey edited comment on QPID-8405 at 1/27/20 11:05 AM:
----------------------------------------------------------------
{quote}I see. So much for standards and their specifications...
{quote}
:) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
{quote}Another suggestion would be to issue a warning if the expiration is way
in the past (e.g. 60,000 in our case). We were using the RabbitMQ client and
QPid as the broker and there are no signs whatsoever that something is going
wrong except that messages simply don't arrive at consumers. After some time
you see a "message discarded" log entry from QPid but that is long after it has
been submitted and in some cases also more or less matched the desired TTL.
{quote}
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 10000 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
Edited to add - you can set a Java system property to change the default
"minimumMessageTtl" for all queues (i.e. all queues which haven't had a minimum
message TTL explicitly set). The system property in question is
{{queue.minimumMessageTtl}}. Note that for messages without an expiration set,
or with an expiration set sufficiently in the future, then setting the minimum
TTL has no effect.
was (Author: rgodfrey):
bq. I see. So much for standards and their specifications...
:-) I will make the excuse that that "definition" was made before I, or the
Rabbit folks, got involved in the spec writing. For AMQP 1.0 we tried to do a
better job of making sure things were defined without ambiguity - though even
there we have found we were ultimately far from perfect.
bq. Another suggestion would be to issue a warning if the expiration is way in
the past (e.g. 60,000 in our case). We were using the RabbitMQ client and QPid
as the broker and there are no signs whatsoever that something is going wrong
except that messages simply don't arrive at consumers. After some time you see
a "message discarded" log entry from QPid but that is long after it has been
submitted and in some cases also more or less matched the desired TTL.
Well, one thing you can do in Qpid is set a minimum message TTL on a Queue - so
if you set the "minimumMessageTtl" attribute on the queue to 10000 (ms) then
any message sent to the queue with an expiration "in the past" will be treated
as having a 10 second TTL.
> Per-message expiration is treated wrong for AMQP 0-9-1
> ------------------------------------------------------
>
> Key: QPID-8405
> URL: https://issues.apache.org/jira/browse/QPID-8405
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-7.1.7
> Reporter: Thorsten Meinl
> Priority: Major
>
> We are using QPid with AMQP 0-9-1 support as an embedded alternative to
> RabbitMQ. RabbitMQ has extended the 0-9-1 specification with [per-message
> TTLs|https://www.rabbitmq.com/ttl.html#per-message-ttl]. The documentation
> states that the value of the {{expiration}} header is the time-to-live in
> milliseconds. However, when we set an expiration of 60,000 when sending a
> message to QPid this message gets discarded immediately and is not delivered
> to any consumer. I had a look at the code and the bug is obvious: instead of
> treating the {{expiration}} header as a TTL it is treated as an absolute
> expiration timestamp, see
> {{org.apache.qpid.server.queue.QueueEntryImpl.expired()}}. Either QPid
> shouldn't support expiration at all for AMPQ 0-9-1 since it's not part of the
> standard or it should follow the RabbitMQ implementation since I assume it
> was introduced by them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
