activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <christopher.l.shan...@gmail.com>
Subject Re: Do all Message usage have to be within onMessage?
Date Mon, 22 Jun 2015 04:16:12 GMT
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 <hzbarcea@gmail.com>
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 <burton@spinn3r.com> 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 Spinn3r.com
>>> Location: *San Francisco, CA*
>>> blog: http://burtonator.wordpress.com
>>> … or check out my Google+ profile
>>> <https://plus.google.com/102718274791889610666/posts>
>>>
>>>
>>

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