Possibly, it's not something I've tried with the Artemis client, I was just mainly pointing out JMS says acknowledge() does nothing if you aren't using the click-ack mode its for. Identifying if there really is a bug with the close-in-auto-ack-listener and perhaps fixing it might be another route.
On Fri, 30 Sept 2022 at 14:51, John Lilley <john.lil...@redpointglobal.com.invalid> wrote: > Robbie, > > > > I am using auto-ack mode generally. So perhaps one solution is to make > this consumer manual-ACK instead? I’ll try that. If it works it will be > easier than changing our code to use consumer.receive(). > > Thanks > > john > > > > > [image: rg] <https://www.redpointglobal.com/> > > John Lilley > > Chief Architect, Redpoint Global Inc. > > 888 Worcester Street, Suite 200 Wellesley, MA 02482 > > *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > > *From:* Robbie Gemmell <robbie.gemm...@gmail.com> > *Sent:* Friday, September 30, 2022 6:49 AM > *To:* users@activemq.apache.org > *Subject:* Re: Processing only one message > > > > **** [Caution] This email is from an external source. Please use caution > responding, opening attachments or clicking embedded links. **** > > > > If you only want to get a single message it might make more sense to use > [possibly non-prefetching if really only wanting 1 message] > consumer.receive(..) style calls rather than a MessageListener. > > > > Opening and closing a consumer and session per-message is quite > inefficient. Are you also closing the connection after each message, or > does the application reuse it to create a new session and consumer+listener > for future work? If the latter it definitely makes sense to just leave the > consumer open and reuse it to get each message in turn. Depending on the > number of consumers and whether they are competing, it may even make sense > to actually use prefetching at that point too. > > > > The reason the session.close() throws is that the original JMS 1.1 spec > described it such that the client should effectively deadlock itself in > that situation. JMS 2 changed the spec description to say it could throw, > as many impls did, or could close, but since it isn't portable as there is > different behaviour, doing so should be avoided. > > > > That said, calling consumer.close() should work, its possible there is a > bug there, depending on what you are doing overall. > > > > You dont say what ack mode you are using. The message.acknowledge() method > is to be ignored for anything but use of the CLIENT_ACK session mode (or > the client has an individual-ack extension/non-JMS ack mode too), at which > point note that it acks all prior messages received on the session, not > just the message it is called on (unless using the extension individual ack > mode is being used, when will only do the message its called on). Though > those would be effectively the same if you only get 1 message at a time. > > > > On Thu, 29 Sept 2022 at 23:01, John Lilley < > john.lil...@redpointglobal.com.invalid> wrote: > > We have an application that should read a single message from a queue (a > “job” queue) and then stop processing more messages. Think of it as a > “batch request”. This is entirely using the JMS driver. Is there a good > pattern for this? > > > > Under ActiveMQ 5, I call consumer.close(), session.close() from > onMessage() and that works fine. However, session.close() is not allowed > under Artemis (and maybe it was always wrong). > > > > I’ve tried calling only consumer.close(), and leave the session open. But > the message is not ACked. Explicitly calling message.acknowledge() doesn’t > work either, because it gets to >>> and individualAck is false: > > > > *public void *acknowledge() *throws *JMSException { > *if *(*session *!= *null*) { > *try *{ > *if *(*session*.isClosed()) { > *throw *ActiveMQClientMessageBundle.*BUNDLE*.sessionClosed(); > } > >>> *if *(*individualAck*) { > *message*.individualAcknowledge(); > } > > > > Going back to the original question, what is the recommended pattern for > this? > > > > Thanks > > john > > > > [image: rg] > <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.redpointglobal.com%2f&c=E,1,0ZDntuxk_EAfCKQLGnMBAyrhnrNZ9KcKhTj_3e7rK3jtFtz3NjCpKV2H_AkznQUD94jByfxPdpOf109Y27PGyw-62M1Pwd77UKKfeOg0BsADuKvpDZFFjEQr&typo=1> > > *John Lilley * > > *Chief Architect, Redpoint Global Inc. * > > 888 Worcester Street, Suite 200 Wellesley, MA 02482 > > *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > > > PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. > > > PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. >
