[rabbitmq-discuss] question on message ordering guarantees
ejsmont.artur at gmail.com
Thu Oct 18 12:25:04 BST 2012
Thanks guys! these were very helpful and quick responses.
I will read the docs you recommended and come back in case of any further
ideas or questions :)
Thanks a lot
On 18 October 2012 22:05, Alexis Richardson <alexis at rabbitmq.com> wrote:
> See the long discussion on ordering posted in the depths of the thread
> Note that Kafka has at most one consumer per 'partition' which is
> equivalent to the property Tim described.
> On Thu, Oct 18, 2012 at 12:03 PM, Alexis Richardson <alexis at rabbitmq.com>
> > If you use the consistent hashing exchange, then you can make sure
> > that two messages with the same key are sent to the same queue. Then,
> > provided you do not allow parallel processing of those messages due to
> > how they are consumed, you can "process in order" as required.
> > On Thu, Oct 18, 2012 at 11:43 AM, Tim Watson <tim at rabbitmq.com> wrote:
> >> Hi
> >> On 10/18/2012 10:30 AM, Artur Ejsmont wrote:
> >> Hi there everyone,
> >> I am working on a rabbitmq based messaging system and i was wondering
> if you
> >> could help me out :)
> >> I was wondering how could i enforce events being processed in the order
> >> are published?
> >> So from http://www.rabbitmq.com/semantics.html, we can see:
> >> "Section 4.7 of the AMQP 0-9-1 core specification explains the
> >> 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.
> >> Messages can be returned to the queue using AMQP methods that feature a
> >> requeue parameter (basic.recover, basic.reject and basic.nack), 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,
> >> are always held in the queue in publication order, even in the presence
> >> requeueing or channel closure.
> >> With release 2.7.0 and later it is still possible for individual
> >> to observe messages out of order if the queue has multiple subscribers.
> >> is due to the actions of other subscribers who may requeue messages.
> >> the perspective of the queue the messages are always held in the
> >> order."
> >> So you've got to think about it in those terms. It's exactly the same
> >> ActiveMQ message groups, because they are based on the Exclusive
> >> 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."
> >> (http://activemq.apache.org/exclusive-consumer.html) except that
> groups are
> >> parallel, so: "... logically Message Groups are kinda like a parallel
> >> Exclusive Consumer. Rather than all messages going to a single
> consumer, the
> >> standard JMS header JMSXGroupID is used to define which message group
> >> message belongs to. The Message Group feature then ensures that all
> >> 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." (http://activemq.apache.org/message-groups.html).
> >> You might be able kludge something similar using the consistent hash
> >> exchange plugin
> >> (
> >> but you will *not* get the same kind of guarantees.
> >> We have been asked about this feature before and will probably implement
> >> something like it in a future release.
> >> Cheers,
> >> Tim
> >> _______________________________________________
> >> rabbitmq-discuss mailing list
> >> rabbitmq-discuss at lists.rabbitmq.com
> >> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Visit me at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss