qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Reject Policy not working
Date Fri, 15 Mar 2019 11:03:38 GMT
If you aren't also using a second non-Azure server then you aren't
actually using qpid-client-6.0.4 at all, as it only supports AMQP 0-8
to 0-10 and not the AMQP 1.0 protocol which Azure uses.

The qpid-amqp-1-0-client-jms-0.32 referenced is an old, originally
prototype, AMQP 1.0 client not released by the project in some time.
Its a separate client and doesnt use any of the configuration you have
described, the 'reject behaviour' you mention is from the AMQP 0-x
client, as is the concept of a 'binding URL', hence why it either had
no effect or caused an error. I believe this client implements
recover() locally and it cant be changed.

Our current AMQP 1.0 JMS client is 'qpid-jms-client', presently at
version 0.40.0 and entirely separate from the above. It also
implements recover() locally and that similarly cant be changed. It
does have Redelivery Policy options though that would let you hand
messages back to the server when hit. Configuring it to use 'reject'
in that scenario will likely make them go straight to the DLQ with
Azure. Those options are detailed in this section of the
docs:http://qpid.apache.org/releases/qpid-jms-0.40.0/docs/index.html#jms-configuration-options

Robbie

On Thu, 14 Mar 2019 at 17:18, Martín Paoloni
<martin.paoloni@mulesoft.com.invalid> wrote:
>
> Hello,
>
> I am using qpid-client 6.0.4 and qpid-amqp-1-0-client-jms 0.322 to
> subscribe to an Azure Service Bus topic, which has DLQ (dead letter queue)
> enabled and a max redelivery count of 2.
>
> When the processing of a received message fails, I'm doing a
> session.recover(). But this seems to dispatch the same message over and
> over again, locally, without sending it back to Azure, and therefore,
> ignoring the max redelivery count configuration.
>
> I have tried setting system property qpid.reject.behaviour to "server", but
> this made no change. Also, adding the option rejectbehaviour to the binding
> URL results in an error message, stating that the option is unknown.
>
> Any ideas?
>
> TL;DR: I need rejected messages to go back to the queue instead of them
> being redispatched locally.
>
> Many thanks!
>
> Martín Paoloni

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


Mime
View raw message