activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Do all Message usage have to be within onMessage?
Date Tue, 23 Jun 2015 01:22:28 GMT

I had to assume you knew :). Sometimes it pays to make it clear for 
other readers.


On 06/22/2015 12:16 AM, Christopher Shannon wrote:
> Hadrian,
> Right, thanks for clarifying that point.  I realized I wasn't super clear
> but that's what I was trying to say, that the client takes responsibility
> of the message from the broker. The only time I've done that in an
> application was rare cases where losing a message was an acceptable trade
> off to increase performance.
> Chris
> On Sun, Jun 21, 2015 at 11:27 PM, Hadrian Zbarcea <>
> wrote:
>> In JMS 2.0 one has shared subscriptions for topics. There was more
>> interest recently around JMS 2.0. I think all the primitives are in place
>> in AMQ, it's just a matter of implementing it. What is a bit of a cause for
>> stress (for me) is the time it takes to run the unit tests.
>> @Christopher, in addition to not being able to roll back you basically
>> take responsibility for the message. If you don't persist, you risk loosing
>> the message if the consumer process goes down.
>> The question is valid though, @Kevin, what exactly are you trying to
>> achieve?
>> Cheers,
>> Hadrian
>> On 06/21/2015 09:14 PM, Christopher Shannon wrote:
>>> Usually, if you think you might need to rollback a message you should just
>>> want to handle that message in onMessage. What is the reason to share
>>> messages between threads?  Is it just to be able to consume more than one
>>> message at a time?  If so I would encourage you to just start multiple
>>> consumers instead of trying to pass messages to another thread from one
>>> consumer.  On of my favorite ways to have multiple consumers and to handle
>>> messages concurrently is to use Spring's DefaultMessageListenerContainer.
>>> JMS is really designed to handle messages in the same thread they were
>>> consumed.  A Session and a MessageConsumer are both only single threaded
>>> and shouldn't be shared across threads, for example.   In the past I have
>>> done something where i've had a message listener receive messages and then
>>> pass them to other threads in a thread pool to increase throughput but I
>>> immediately acknowledged the messages before passing them.  This has the
>>> disadvantage of not being able to roll back if something happens during
>>> processing.
>>> If really want to try and pass messages to other threads you might be able
>>> to get something to work if you use individual acknowledgement since only
>>> a
>>> single message will be acknowledged. (I haven't tested this so I could be
>>> wrong) Trying to forward a message to another thread while using
>>> transactions won't work because when you call commit all messages received
>>> since the last commit would be committed. The same for client acknowledge
>>> mode.
>>> On Sun, Jun 21, 2015 at 6:41 PM, Kevin Burton <> wrote:
>>>   If you’re using a MessageListener, what’s the best way to use that
>>>> Message
>>>> in other threads? I was thinking of reading the message as a string, then
>>>> forwarding the *string* to other threads, with just a reference to the
>>>> message.  Then stick it back in a queue so that the original thread can
>>>> commit the message.
>>>> --
>>>> Founder/CEO
>>>> Location: *San Francisco, CA*
>>>> blog:
>>>> … or check out my Google+ profile
>>>> <>

View raw message