activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <>
Subject Re: Do all Message usage have to be within onMessage?
Date Mon, 22 Jun 2015 04:16:12 GMT

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.


On Sun, Jun 21, 2015 at 11:27 PM, Hadrian Zbarcea <>

> 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
>>> <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message