Manual acknowledge within JMS message listener

[pela <mp...@gmail.com>]

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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Manual acknowledge within JMS message listener

[Robbie Gemmell <ro...@gmail.com>]

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 <mp...@gmail.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>