Hi Marco, You are correct that doing a long running task in onMessage will prevent another messages being delivered to other listeners, but it should be noted that this would only be on that session, so you could use multiple sessions and multiple consumers. Also, you don't need to call acknowledge after every message, so you could do it in batches, but obviously by using onMessage you have no real way of telling when the next message will arrive so that is always going to be an issue (particularly for the last message).
Alternatively, instead of using onMessage() at all you could use a synchronous receive() call on a consumer and offload the actual message processing to other threads, calling acknowledge only after reaching a certain threshold (e.g a certain number of messages, or when you have consumed all of the currently available messages, i.e when a null is returned) and confirming the previously recieved messages have now been asynchronously processed. You would need to balance the receive() timeout such that it is high enough to prevent excessive busy looping but low enough to still allow determining quickly enough for your needs that you have consumed all the messages currently available. You could also just use multiple consumers with receive() calls and forego the other threads. For what its worth, Spring's DefaultMessageListenerContainer actually uses synchronous recieve() calls with timeouts behind the covers. Robbie On 12 November 2013 10:11, pela <[email protected]> wrote: > Hello, > > In my application based on QPID JMS, I have a session created in > CLIENT_ACKNOWLEDGE mode, which uses a MessageListener for anynchronous > message processing. As far as I understand from the JMS specs, in this > case: > > 1) After processing of each message, the message acknowledge() method must > be called. This will implicitly acknowledge all messages received so far on > the session. > > 2) The acknowledge() method must be called from within onMessage() of the > MessageListener implementation. > > If my understanding is correct, then the processing and storage of the > message, which can be a lengthy operation such as committing to a database, > will have to be synchronous and block the onMessage, thus preventing > further > messages to be de-queued in the meantime. > > Is this the way it works? Isn't there any other way to make the processing > asynchrounous but preserving the reliability? > > Thanks for any advice > > Marco > > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Manual-acknowledge-within-JMS-message-listener-tp7600630.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
