Thanks guys! these were very helpful and quick responses.�<div><br></div><div>I will read the docs you recommended and come back in case of any further ideas or questions :)</div><div><br></div><div>Thanks a lot</div><div>
<br></div><div>Art<br><br><div class="gmail_quote">On 18 October 2012 22:05, Alexis Richardson <span dir="ltr"><<a href="mailto:alexis@rabbitmq.com" target="_blank">alexis@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
See the long discussion on ordering posted in the depths of the thread here:<br>
<br>
<a href="http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-for-durable-messaging-with-good-query-features/" target="_blank">http://www.quora.com/RabbitMQ/RabbitMQ-vs-Kafka-which-one-for-durable-messaging-with-good-query-features/</a><br>
<br>
Note that Kafka has at most one consumer per 'partition' which is<br>
equivalent to the property Tim described.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Oct 18, 2012 at 12:03 PM, Alexis Richardson <<a href="mailto:alexis@rabbitmq.com">alexis@rabbitmq.com</a>> wrote:<br>
> If you use the consistent hashing exchange, then you can make sure<br>
> that two messages with the same key are sent to the same queue. �Then,<br>
> provided you do not allow parallel processing of those messages due to<br>
> how they are consumed, you can "process in order" as required.<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Oct 18, 2012 at 11:43 AM, Tim Watson <<a href="mailto:tim@rabbitmq.com">tim@rabbitmq.com</a>> wrote:<br>
>> Hi<br>
>><br>
>><br>
>> On 10/18/2012 10:30 AM, Artur Ejsmont wrote:<br>
>><br>
>> Hi there everyone,<br>
>><br>
>> I am working on a rabbitmq based messaging system and i was wondering if you<br>
>> could help me out :)<br>
>><br>
>> I was wondering how could i enforce events being processed in the order they<br>
>> are published?<br>
>><br>
>><br>
>> So from <a href="http://www.rabbitmq.com/semantics.html" target="_blank">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<br>
>> under which ordering is guaranteed: messages published in one channel,<br>
>> passing through one exchange and one queue and one outgoing channel will be<br>
>> received in the same order that they were sent. RabbitMQ offers stronger<br>
>> guarantees since release 2.7.0.<br>
>><br>
>> Messages can be returned to the queue using AMQP methods that feature a<br>
>> requeue parameter (basic.recover, basic.reject and basic.nack), or due to a<br>
>> channel closing while holding unacknowledged messages. Any of these<br>
>> scenarios caused messages to be requeued at the back of the queue for<br>
>> RabbitMQ releases earlier than 2.7.0. From RabbitMQ release 2.7.0, messages<br>
>> are always held in the queue in publication order, even in the presence of<br>
>> requeueing or channel closure.<br>
>><br>
>> With release 2.7.0 and later it is still possible for individual consumers<br>
>> to observe messages out of order if the queue has multiple subscribers. This<br>
>> is due to the actions of other subscribers who may requeue messages. From<br>
>> the perspective of the queue the messages are always held in the publication<br>
>> order."<br>
>><br>
>> So you've got to think about it in those terms. It's exactly the same with<br>
>> ActiveMQ message groups, because they are based on the Exclusive Consumer<br>
>> feature, which states: "The broker will pick a single MessageConsumer to get<br>
>> all the messages for a queue to ensure ordering. If that consumer fails, the<br>
>> broker will auto failover and choose another consumer."<br>
>> (<a href="http://activemq.apache.org/exclusive-consumer.html" target="_blank">http://activemq.apache.org/exclusive-consumer.html</a>) except that groups are<br>
>> parallel, so: "... logically Message Groups are kinda like a parallel<br>
>> Exclusive Consumer. Rather than all messages going to a single consumer, the<br>
>> standard JMS header JMSXGroupID is used to define which message group the<br>
>> message belongs to. The Message Group feature then ensures that all messages<br>
>> for the same message group will be sent to the same JMS consumer - while<br>
>> that consumer stays alive. As soon as the consumer dies another will be<br>
>> chosen." (<a href="http://activemq.apache.org/message-groups.html" target="_blank">http://activemq.apache.org/message-groups.html</a>).<br>
>><br>
>> You might be able kludge something similar using the consistent hash<br>
>> exchange plugin<br>
>> (<a href="http://hg.rabbitmq.com/rabbitmq-consistent-hash-exchange/file/rabbitmq_v2_8_7/README.md" target="_blank">http://hg.rabbitmq.com/rabbitmq-consistent-hash-exchange/file/rabbitmq_v2_8_7/README.md</a>)<br>
>> but you will *not* get the same kind of guarantees.<br>
>><br>
>> We have been asked about this feature before and will probably implement<br>
>> something like it in a future release.<br>
>><br>
>> Cheers,<br>
>> Tim<br>
>><br>
>> _______________________________________________<br>
>> rabbitmq-discuss mailing list<br>
>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Visit me at:<br><a href="http://artur.ejsmont.org/blog/" target="_blank">http://artur.ejsmont.org/blog/</a><br><br>
</div>