Message reception order by topic consumers across sessions
btrip Mar 29, 2012 5:13 AMWe are trying to understand in which messages in a HornetQ topic are consumed by clients. More specifically, we have the following scenario:
- A single producer is spawned each minute by a quartz job, generates a set of messages and sends them to a topic, ordered in a specific manner (database timestamp)
- Multiple consumers are subscribed to the topic
Questions:
a) Will the consumers always receive the messages from the topic in the same order as the producer put them in the topic?
b) If not, is there any way to guarantee that the ordering will be correct, by other means (e.g. by replacing topics with queues, one per consumer?). We are only interested in the order in which each consumer receives the messages, not the overall order amongst consumers. However, we are interested in the order of message reception extending beyond the producer lifetime, i.e. if message A is sent the first time the producer is spawned and message B is sent the second time the producer is spawned, then message A should be received by each consumer before it receives message B.
We have not seen a clear enough answer on this question, although there are hints in the JMS spec that the ordering of the messages is only guaranteed in a single session, which in our example is not the case (the producer will create a new session every time it is spawned).
Also, in the FAQ section, we have found the following sentence:
"HornetQ will always guarantee order of delivery at the producer level if you use a single consumer per queue without selectors.". Does this mean that the order of delivery to consumers is only guaranteed to be the same as the order the messages were added to the queue within a single JMS session, and messages added in different sessions may arrive in different order than the order in which they were added to the queue?
We are very interested in performance, so the option of disabling buffering on the consumer is not acceptable. Furthermore, the solution of message groups cannot be applied to our requirements due to specific business requirements.
Many thanks,
Babis