4 ms·

Not yet, but reading the docs. Has 'once only delivery' which is good. Still trying to find if it does FIFO (i think its hard to achieve this in a distributed s

Not yet, but reading the docs. Has 'once only delivery' which is good. Still trying to find if it does FIFO (i think its hard to achieve this in a distributed system).

oweiler 6y ago
What do you mean by FIFO? Messages delivered in insertion order? With Kafka, this is easy: messages with the same key land in the same partition. I guess Pulsar offers something similar.
jackvanlightly 6y ago
Yes it does FIFO. Just like RabbitMQ, Apache Kafka and many other distributed systems, writes go through an elected leader, who is able to ensure ordering guarantees. Specifically with Apache Pulsar, each topic has an owner broker (leader) who accepts writes and serves readers. It should be noted that Apache Pulsar supports shared subscriptions which allow two or more consumers to compete for the same messages, like having two consumers on a RabbitMQ queue. Here FIFO order cannot be guaranteed for all kinds of reasons.
- SuddsMcDuff 6y ago
  See also: competing consumers pattern https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html https://www.enterpriseintegrationpatterns.com/patterns/messa...
dikei 6y ago
https://pulsar.apache.org/docs/en/concepts-messaging/#ordering-guarantee https://pulsar.apache.org/docs/en/concepts-messaging/#orderi... Basically, they have the same ordering guarantee as Kafka: FIFO is guaranteed for messages from the same producer, within the same partition. If you need producer-level FIFO, then you can only use 1 partition. There's no ordering guarantee for messages coming from different producer.
- eis 6y ago
  To add: In a distributed system, an ordering guarantee by producer (and optionally partition "key" which in the end is like an extension of the topic key) is pretty much all you need and all you can get. If you have two producers then how would one decide which one sent the message first? Go by some timestamp? Clocks are unreliable for these purposes so it comes down to consesus. And letting the queue decide which one came first is equivalent. Once a message got acknowledged by the queue, ordering cannot change anymore.

Not yet, but reading the docs. Has 'once only delivery' which is good. Still trying to find if it does FIFO (i think its hard to achieve this in a distributed system).

oweiler 6y ago

What do you mean by FIFO? Messages delivered in insertion order? With Kafka, this is easy: messages with the same key land in the same partition. I guess Pulsar offers something similar.

jackvanlightly 6y ago

Yes it does FIFO. Just like RabbitMQ, Apache Kafka and many other distributed systems, writes go through an elected leader, who is able to ensure ordering guarantees. Specifically with Apache Pulsar, each topic has an owner broker (leader) who accepts writes and serves readers. It should be noted that Apache Pulsar supports shared subscriptions which allow two or more consumers to compete for the same messages, like having two consumers on a RabbitMQ queue. Here FIFO order cannot be guaranteed for all kinds of reasons.

SuddsMcDuff 6y ago
See also: competing consumers pattern https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html https://www.enterpriseintegrationpatterns.com/patterns/messa...

dikei 6y ago

https://pulsar.apache.org/docs/en/concepts-messaging/#ordering-guarantee https://pulsar.apache.org/docs/en/concepts-messaging/#orderi... Basically, they have the same ordering guarantee as Kafka: FIFO is guaranteed for messages from the same producer, within the same partition. If you need producer-level FIFO, then you can only use 1 partition. There's no ordering guarantee for messages coming from different producer.

eis 6y ago
To add: In a distributed system, an ordering guarantee by producer (and optionally partition "key" which in the end is like an extension of the topic key) is pretty much all you need and all you can get. If you have two producers then how would one decide which one sent the message first? Go by some timestamp? Clocks are unreliable for these purposes so it comes down to consesus. And letting the queue decide which one came first is equivalent. Once a message got acknowledged by the queue, ordering cannot change anymore.