[GitHub] [pulsar] pulsar-community-bot edited a comment on the discussion: Resetting Cursors

[GitBox <gi...@apache.org>]

GitHub user pulsar-community-bot edited a comment on the discussion: Resetting Cursors

**From David K**

Every subscription is shared by one or more consumers. All of the consumers on the subscription will resume consumption from the reset position.
[5:38](https://apache-pulsar.slack.com/archives/C5Z4T36F7/p1677256699535269)
The subscription is used on the broker side to determine where to read the messages from and dispatch to the next consumer on the subscription.

**From @sothmann**

I'm particularly thinking about a key shared subscription. If I have two consumers A and B, they would get different messages based on the key of the messages. So I would have thought that each consumer would have its own cursor. But it sounds like the subscription has just one shared cursor. Is that accurate? The statement "A Cursor is a subscription position for a consumer." is then not correct I guess. (edited) 

**From David K**

For the Key-shared subscription there is a different mechanism on the Broker side that tracks the assignment of the consumers on the subscription to a set of keys, e.g. a key-range. The cursor keeps track of the overall subscription position, while these key-ranges are used to route the message to the corresponding consumers based on their assigned key-range(s).

**From @sothmann**

In the example with consumers A and B, lets say consumer A gets key range A-J, consumer B gets key range K-Z assigned.
Now they will process messages in parallel, but each consumer processes the messages in its key range sequentially.
They can be at different positions in the topic as they work concurrently (especially if one consumer is faster than the other or if more messages come with keys in one of the two key ranges).
If there is a single cursor per subscription, what will it track in this case? What is the "overall subscription position"?
Sorry if this is a dumb question, but it hasn't really clicked for me yet.

**From David K**

For a non-partitioned topic, the cursor reset is the same as any other subscription type. It just moves the cursor to the message closest to the timestamp or messageId provided. Then as the Broker dispatches the messages it reads through the topic and “routes” the messages to the consumer based on the key.
[6:18](https://apache-pulsar.slack.com/archives/C5Z4T36F7/p1677259121064129)
For a partitioned topic, cursor management is bit more complicated, because we really need to manage multiple cursors inside a single subscription. This is all handled transparently from the consumers, but essentially there is one cursor per partition. When a reset occurs then all of these cursors are independently  moved to the message closest to the timestamp or messageId provided, and consumption resumes from there.

GitHub link: https://github.com/apache/pulsar/discussions/19634#discussioncomment-5102846

----
This is an automatically sent email for commits@pulsar.apache.org.
To unsubscribe, please send an email to: commits-unsubscribe@pulsar.apache.org