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 <hzbar...@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 <bur...@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> >>> >>> >>
