Closed Obiwan1995 closed 1 year ago
Hi,
My understanding is that unlike AMQP 0.9.1, the AMQP 1.0 protocol does not define the behaviour of the broker when a message is rejected as quoted below (and you can refer to [1]), and thus, whether a message is removed from the queue upon rejection is likely broker specific.
At the target, the rejected outcome is used to indicate that an incoming message is invalid and therefore unprocessable. The rejected outcome when applied to a message will cause the delivery-count to be incremented in the header of the rejected message.
As for your specific use case, release
(see [1] and [2]) seems to be more fitting than reject
. What you mentioned above
... indicate to the broker that the message has not been processed and therefore this message would be re-queued for re-delivery.
looks like almost exactly how release
is decribed in qpid-proton
(see [2])
Releases a received message, making it available at the source for any (other) interested receiver.
I think fe2o3-amqp
handles release the same way as qpid-proton
.
[1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-delivery-state [2] https://qpid.apache.org/releases/qpid-proton-0.33.0/proton/python/docs/proton.handlers.html?highlight=auto#proton.handlers.Release
Hi @Obiwan1995, the maximum delivery count setting for your qpid broker may also affect this behaviour. https://qpid.apache.org/releases/qpid-broker-j-8.0.2/book/Java-Broker-Runtime-Handling-Undeliverable-Messages.html#Java-Broker-Runtime-Handling-Undeliverable-Messages-Maximum-Delivery-Count
@Obiwan1995 I am not very familiar with java but it looks like qpid-broker-j
will delete the message upon rejection
It was unclear for me what the purpose of release
was but you made it a lot clearer :) The message is indeed re-delivered, just the way I was looking for.
Thanks for your help!
Hello,
I have an issue when using the
reject
method on aReceiver
. I thought that rejecting a message would indicate to the broker that the message has not been processed and therefore this message would be re-queued for re-delivery.But it seems that rejecting messages is the same as accepting them: message is dropped from the queue and never re-delivered. Re-delivery occurs when I don't accept nor reject a message (but only when re-creating the
Receiver
).Is there a way to tell the broker that I want the message to be re-queued?
For reference, I'm using Apache Qpid broker.