[
https://issues.apache.org/jira/browse/QPID-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830303#comment-15830303
]
James Howe edited comment on QPID-6468 at 1/19/17 5:34 PM:
-----------------------------------------------------------
Just to note that the current implementation violates 0-9-1.
In particular, the {{requeue}} bit of {{basic.reject}} is ignored and the
message will always be requeued unless maximum delivery count is exceeded.
{quote}
If requeue is true, the server will attempt to requeue the message. If requeue
is false or the requeue attempt fails the messages are discarded or
dead-lettered.
The server MUST NOT deliver the message to the same client within the context
of the current channel. The recommended strategy is to attempt to deliver the
message to an alternative consumer, and if that is not possible, to move the
message to a dead-letter queue. The server MAY use more sophisticated tracking
to hold the message on the queue and redeliver it to the same client at a later
stage.
{quote}
I think the second paragraph is violated by most implementations though,
because it's stupid.
was (Author: jameshowe):
Just to note that the current implementation violates 0-9-1.
In particular, the {{requeue}} bit of {{basic.reject}} is ignored and the
message will always be requeued unless maximum delivery count is exceeded.
{quote}
> [0-8..0-91] Use basic.nack for releasing messages back to the Broker for
> delivery elsewhere
> -------------------------------------------------------------------------------------------
>
> Key: QPID-6468
> URL: https://issues.apache.org/jira/browse/QPID-6468
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker, Java Client
> Reporter: Keith Wall
>
> The Java Broker/Client historically has abused AMQP [0-8..0-91] basic.reject
> to release messages back to the Broker if the client no longer intends to
> deliver them to the application (for example, the closing of a consumer
> requires that messages that were optimistically prefetched now must be made
> available for delivery elsewhere and must be released to the Broker). This
> was never the intended use for basic.reject.
> QPID-6164 introduced (the Rabbit specific) AMQP extension basic.nack to allow
> for synchronous publishing. We can make use of the same mechanism (as do
> Rabbit) for implementing message release on consuming side too.
> This would tidy up lots of ugly code around the DLQ support within the Java
> Broker, and allow the Qpid components to interop better with the Rabbit
> components.
> Compatibility between older versions would need to be retained.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
