Your example race condition isn't a race condition; if you publish two identical messages, they will both be consumed irrespective of whether that consumption is concurrent or sequential, because they're two different messages (even though they have the same content).
In any messaging system, you have the choice between at-least-once processing and at-most-once processing, where the difference is whether you should attempt to reprocess messages that failed processing the first time for whatever reason. If you're not using an idempotent consumer, your only safe option is at-most-once processing, which ActiveMQ defaults to by defaulting to AUTO_ACK acknowledgement mode, but it's always a good practice to use an idempotent consumer even if you're using AUTO_ACK mode. The caveat to all of what I just wrote is that if your consumer can be written in a way that all actions can be wrapped in a transaction that can be rolled back, you can avoid duplicate results of processing (though of course you'll have processed more than once, you just will have discarded all but one of the results when you rolled back the transaction). But not all actions can be rolled back, so this doesn't help in all cases. The most obvious race condition I know of is the case where a topic message is sent when you're not sure whether the consumer is already connected (and might or might not get it as a result). Depending on what you're trying to do, you can sometimes work around the problem by having the producer wait to send the message till the consumer is subscribed. Good luck with your research project. Tim On Fri, Aug 19, 2016 at 9:39 PM, joshhendo <joshhe...@outlook.com> wrote: > Hi Everyone, > > Firstly, I just wanted to quickly say hi as I'm new to the Active MQ > community. > > I'm doing a research project on different ways that people have overcome > race conditions when using message queues. As such, I'm looking to do an > informal survey throughout various communities that use message queues, to > find out what kind of problems people have seen (if any), and what > approaches and designs they've used to help minimize or avoid race > conditions. > > An example scenario that I'm thinking of is, the same message is > (accidentally) sent multiple times, and with the receiving program > processing messages in parallel across multiple threads, the same message > is > processed multiple times simultaneously, causing unexpected results (this > scenario is based around the message being processed in parallel; a race > condition probably wouldn't occur if the same message was sent a second > time > after the first message was fully processed). > > It could be that many people haven't experienced such issues, or that > there's a common theme to avoiding such issues (e.g. ensuring every message > is idempotent). However, if anyone has had any experience with such > scenarios, I'd very interested in finding out more about your experiences. > > Thanks! > Josh Henderson > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/What-methods-have-people-used-to-overcome-race- > conditions-tp4715676.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
