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 < [email protected]> 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. >
