On Mon, 2015-12-07 at 10:29 +0000, Robbie Gemmell wrote:
> On 4 December 2015 at 19:56, Philippe Le Rohellec <p...@microsoft.com>
> > I'm using Proton to receive messages from an Azure Service Bus
> > queue.
> > The receiver keeps a lock on each message it receives for a
> > predefined
> > amount of time, which I think matches the "Lock Duration" set on
> > the queue
> > on the Azure side. The max value in Azure is 5 minutes.
> > What if processing the message takes more than 5 minutes? Is there
> > a way to
> > renew the lock using Proton or are the 5 minutes non negotiable? I
> > didn't
> > find anything in the API.
> > --
> > View this message in context: http://qpid.2158936.n2.nabble.com/Ext
> > ending-the-lease-duration-on-messages-received-with-Proton
> > -tp7634944.html
> > Sent from the Apache Qpid Proton mailing list archive at
> > Nabble.com.
> Hi Philippe,
> I believe the locking you mention is handled server-side, I'm not
> that the Proton reciever is ever aware of it. I think you'll need to
> ask the Azure folks about whether there is a way to adjust/renew the
May be a conflict of terminology here: AMQP doesn't define a "lock" but
it does define "settlement" of a message. Messages can be sent "pre
settled" which means the sender just fires-and-forgets, or "unsettled"
which means the sender is expecting some acknowledgement. I don't know
Azure but on most brokers (or any system with reliable delivery) that
does amount to a "lock" - the broker sends a message unsettled and will
not send it to any other receiver until it is acknolwedged.
AMQP lets the receiver respond to a message with "accept" (I took it),
"reject" (the message is invalid) or "release" (I didn't take it but
you can try somebody else.) Proton lets you control what response the
receiver sends back and when.
AMQP also lets you define a message "timeout" which says "if the
message is not processed by this time, forget it." So some combination
of acks and timeouts will probably let you do what you want.
(Obviously using timeouts in a network creates the possibility of
occasional duplicate processing, but if you have pre-emptive server
-side lock breaking in Aure you probably know that already ;)