If his understanding is correct, the last paragraph of Chris's first response in this thread seems especially relevant: if you're going to spawn work off into other threads while using transactions (as implied by your reference to commit() in the other post), you either need to wait for your worker thread to finish before taking the next message or you need to be very careful to only ack the latest message for which the worker thread has finished and there are no earlier messages for which the worker thread has not finished. If you pull messages 1-5 and the worker threads finish in the order 3-1-4-2-5, your transaction commits should be none, 1, none, 2-and-3, 4-and-5. The same would be true for client ack mode. Individual ack mode, on the other hand, would let you ack each of those messages as their worker thread finishes.
Same as for Chris, I haven't tested this (nor ever used transactions), so validate what I'm saying before you rely on it. Tim On Sun, Jun 21, 2015 at 10:16 PM, Christopher Shannon < christopher.l.shan...@gmail.com> 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 <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> > >>> > >>> > >> >
