You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alessandro Crotti - SMC Consulting <a....@smcconsulting.it> on 2018/12/17 16:28:23 UTC
Qpid JMS 0.11.1 AMQP 1.0 client - How can be delayed next consuming
attempt after a consuming failed
Hi,
I have this needs:
* I receive message M1
* I process M1 and for a particular scenario I can't process this
message right now
* If I send back ackType MODIFIED_FAILED, the message will be
immediately available for another consuming attempt, but I would
like to "delay" it a bit. In this way I can receive other messages
and then, in the next consuming attempt, probably this message M1
can be consumed successfully.
We consume messages from Azure Service Bus queue and asking their
experts how to delay next consuming message attempts, they told us: for
those messages you shouldn't send any acknowledge, just "let them go",
in this way Azure Service Bus keeps them locked until "Duration Lock"
expires. "Duration Lock" is the period of time that the queue waits for
an acknowledge, if it expires, the message is considered lost and it
comes available for another message consuming attempt.
I tried to avoid acknowledge for this kind of messages, but I noticed
this behavior:
* I receive message M1
* I process M1 and for a particular scenario I can't process this
message right now
* I avoid to send acknowledge and so method "onMessage()" finishes
* I receive message M2
* I process M2 successfully
* I call acknowledge with acktype ACCEPTED for M2.
o Qpid library uses ACCEPTED ackType for all messages which are
not yet acknowleged, so it sends ACCEPTED even for M1.
Having this behavior, I must send acknowledge for each message,
otherwise I could send the wrong ackType.
My questions are:
* Is this a bug or a feature this behavior of sending acknowledge even
for all messages not yet acknowledged?
* Is there a best practise to delay a next consuming attempt after a
consuming failed?
Best Regards
--
SMC Consulting <http://www.smcconsulting.it>
facebook <http://www.facebook.com/SMC-Consulting-Srl-597548223675024/>
linkeding <http://www.linkedin.com/company/smc-consulting-srl>
*Alessandro Crotti*
Senior Developer
tel: +39 342 573 4450
skype: crotti.alessandro
*SMC Consulting* <http://www.smcconsulting.it>
Via dell'industria, 87 41012 Carpi (MO) - Italy
tel: +39 059 664875
CONFIDENTIALITY NOTICE: This message may contain confidential and/or
privileged information.
If you are not the intended recipient, please do not use its contents
for any purpose, advise
the sender immediately by reply e-mail and delete this message and any
attachments without retaining a copy.
Re: Qpid JMS 0.11.1 AMQP 1.0 client - How can be delayed next
consuming attempt after a consuming failed
Posted by Robbie Gemmell <ro...@gmail.com>.
Use the users mailing list for things like this in future. Its a user
question, there is less noise from issues etc traffic that might cause it
to be missed, and there is a bigger audience.
As to the questions, no that observation isnt a bug, its mandated JMS
behaviour that calling acknowledge() acts on all previously received
unacked messages on the session. The same applies even when using the
ability from QPIDJMS-121 to manipulate the disposition type sent, which is
noted on the JIRA [1]. It was envisaged we would extend things to support
individual-ack at the point when JMS 2.1 added it since it had already been
discussed for addition, but JMS 2.1 was later cancelled by Oracle. We will
see where things go now JMS has moved to JakartaEE.
About the only way I can think of for you to delay specific message acks
like that (behaviour distinctly not expected by JMS) is closing your
consumer and creating a new one on another session then closing or acking
the original session later.
[1]
https://issues.apache.org/jira/browse/QPIDJMS-121?focusedCommentId=14967894&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14967894
Robbie
On Mon, 17 Dec 2018 at 16:28, Alessandro Crotti - SMC Consulting <
a.crotti@smcconsulting.it> wrote:
> Hi,
>
> I have this needs:
>
> - I receive message M1
> - I process M1 and for a particular scenario I can't process this
> message right now
> - If I send back ackType MODIFIED_FAILED, the message will be
> immediately available for another consuming attempt, but I would like to
> "delay" it a bit. In this way I can receive other messages and then, in the
> next consuming attempt, probably this message M1 can be consumed
> successfully.
>
> We consume messages from Azure Service Bus queue and asking their experts
> how to delay next consuming message attempts, they told us: for those
> messages you shouldn't send any acknowledge, just "let them go", in this
> way Azure Service Bus keeps them locked until "Duration Lock" expires.
> "Duration Lock" is the period of time that the queue waits for an
> acknowledge, if it expires, the message is considered lost and it comes
> available for another message consuming attempt.
>
> I tried to avoid acknowledge for this kind of messages, but I noticed this
> behavior:
>
> - I receive message M1
> - I process M1 and for a particular scenario I can't process this
> message right now
> - I avoid to send acknowledge and so method "onMessage()" finishes
> - I receive message M2
> - I process M2 successfully
> - I call acknowledge with acktype ACCEPTED for M2.
> - Qpid library uses ACCEPTED ackType for all messages which are not
> yet acknowleged, so it sends ACCEPTED even for M1.
>
> Having this behavior, I must send acknowledge for each message, otherwise
> I could send the wrong ackType.
>
> My questions are:
>
> - Is this a bug or a feature this behavior of sending acknowledge even
> for all messages not yet acknowledged?
> - Is there a best practise to delay a next consuming attempt after a
> consuming failed?
>
> Best Regards
> --
> [image: SMC Consulting] <http://www.smcconsulting.it>
>
> [image: facebook]
> <http://www.facebook.com/SMC-Consulting-Srl-597548223675024/> [image:
> linkeding] <http://www.linkedin.com/company/smc-consulting-srl> *Alessandro
> Crotti*
> Senior Developer
>
> tel: +39 342 573 4450
> skype: crotti.alessandro
>
> *SMC Consulting* <http://www.smcconsulting.it>
> Via dell'industria, 87 41012 Carpi (MO) - Italy
> tel: +39 059 664875
> CONFIDENTIALITY NOTICE: This message may contain confidential and/or
> privileged information.
> If you are not the intended recipient, please do not use its contents for
> any purpose, advise
> the sender immediately by reply e-mail and delete this message and any
> attachments without retaining a copy.
>