This message was deleted.
# general
s
This message was deleted.
✅ 1
b
In regards to your question about Guarentees in Key shared Igor
Copy code
Key Shared Subscription type guarantees a key will be processed by a single consumer at any given time. When a new consumer is connected, some keys will change their mapping from existing consumers to the new consumer. Once the connection has been established, the broker will record the current read position and associate it with the new consumer. The read position is a marker indicating that messages have been dispatched to the consumers up to this point, and after it, no messages have been dispatched yet. The broker will start delivering messages to the new consumer only when all messages up to the read position have been acknowledged. This will guarantee that a certain key is processed by a single consumer at any given time. The trade-off is that if one of the existing consumers is stuck and no time-out was defined (acknowledging for you), the new consumer won't receive any messages until the stuck consumer resumes or gets disconnected.
when there is key based produce to the topic, the messages with same key go to the same partition of the topic
mostly this concept of using N partitions is to make sure topic is served by multiple brokers to avoid resource constraints in single node
i
Thx for the reply. So, if I understand you correctly, you're saying that Pulsar will guarantee the order no matter how many partitions topic has. This sounds really cool!) Do you have any info on how this actually works? I'd like to understand what will happen on increasing the number of partitions. In other words, when there are two messages in two different partitions with the same key hash, how will Pulsar decide which one should be processed first?
b
No worries at all. Seems like David K got this answered in the other thread.
👍 1
p
@Igor Morozov The ordering dispatch is only for one partition, not multiple partitions. If you send the message with a key. All the messages with the same key will go to the same partition. So you should not have messages with same key, but distributed to multiple partitions.
🙌 2
i
Thank you for clarification. Perhaps this should be more explicitly described in the docs, because, currently, it says
There is no difference between partitioned topics and normal topics in terms of how subscription types work.
This can lead to unexpected results... And if I'm not mistaken, adding more partitions to the existing topic will lead to having messages with the same key in different partitions at the same time
p
Yes. update partitions is another story 😂