<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
On 10/18/2012 10:30 AM, Artur Ejsmont wrote:
<blockquote
cite="mid:CABv2Cn2J758KHSuT8ix5dczV3qA5-Xihospc7yzHwRQjSYpiLA@mail.gmail.com"
type="cite">Hi there everyone,
<div><br>
</div>
<div>I am working on a rabbitmq based messaging system and i was
wondering if you could help me out :)</div>
<div><br>
</div>
<div>I was wondering how could i enforce events being processed in
the order they are published? </div>
<div><br>
</div>
</blockquote>
<br>
So from <a class="moz-txt-link-freetext" href="http://www.rabbitmq.com/semantics.html">http://www.rabbitmq.com/semantics.html</a>, we can see:<br>
<br>
"Section 4.7 of the AMQP 0-9-1 core specification explains the
conditions under which ordering is guaranteed: messages published in
one channel, passing through one exchange and one queue and one
outgoing channel will be received in the same order that they were
sent. RabbitMQ offers stronger guarantees since release 2.7.0.
<p> Messages can be returned to the queue using AMQP methods that
feature a requeue parameter (<span class="code ">basic.recover</span>,
<span class="code ">basic.reject</span> and <span class="code ">basic.nack</span>),
or due to a channel closing while holding unacknowledged messages.
Any of these scenarios caused messages to be requeued at the back
of the queue for RabbitMQ releases earlier than 2.7.0. From
RabbitMQ release 2.7.0, messages <b>are always held in the queue
in publication order</b>, <b>even in the presence of requeueing
or channel closure</b>. </p>
<p> With release 2.7.0 and later <b>it is still possible for
individual consumers to observe messages out of order if the
queue has multiple subscribers</b>. This is due to the actions
of other subscribers who may requeue messages. From the
perspective of the queue the messages are always held in the
publication order."</p>
So you've got to think about it in those terms. It's exactly the
same with ActiveMQ message groups, because they are based on the
Exclusive Consumer feature, which states: "The broker will pick a
single MessageConsumer to get all the messages for a queue to ensure
ordering. If that consumer fails, the broker will auto failover and
choose another consumer."
(<a class="moz-txt-link-freetext" href="http://activemq.apache.org/exclusive-consumer.html">http://activemq.apache.org/exclusive-consumer.html</a>) except that
groups are parallel, so: "... logically Message Groups are kinda
like a parallel <a
href="http://activemq.apache.org/exclusive-consumer.html"
title="Exclusive Consumer">Exclusive Consumer</a>. Rather than all
messages going to a single consumer, the standard JMS header <b>JMSXGroupID</b>
is used to define which <em>message group</em> the message belongs
to. The Message Group feature then ensures that all messages for the
same message group will be sent to the same JMS consumer - while
that consumer stays alive. As soon as the consumer dies another will
be chosen." (<a class="moz-txt-link-freetext" href="http://activemq.apache.org/message-groups.html">http://activemq.apache.org/message-groups.html</a>).<br>
<br>
You might be able kludge something similar using the consistent hash
exchange plugin
(<a class="moz-txt-link-freetext" href="http://hg.rabbitmq.com/rabbitmq-consistent-hash-exchange/file/rabbitmq_v2_8_7/README.md">http://hg.rabbitmq.com/rabbitmq-consistent-hash-exchange/file/rabbitmq_v2_8_7/README.md</a>)
but you will *not* get the same kind of guarantees.<br>
<br>
We have been asked about this feature before and will probably
implement something like it in a future release.<br>
<br>
Cheers,<br>
Tim<br>
</body>
</html>