In those instances where the reading will be done from the "cache" of negatively acknowledged messages, it will update the read position?

The read position of the Cursor is a marker, reads above or equal to this marker are called Sequentially Read, and reads below this marker are called Message Replay Read(these messages have been read once by Sequentially Read before), and Specified Read does not care about this marker(in fact, Specified Read does not even care about Cursor).

In general, Message Replay Read does not modify the read position, except in the scenario A compensation mechanism of Message Replay Read below.

Ok. First, let me try to phrase your idea in my words. Tell me if I'm correct:

You're basically adding a variable to a cursor, named (my name, of course) readPositionExternalResetCount. This variable will be increase when ever the read position is about to be reset to some value, initiated by an external action like reset-subscription, rewind, etc.

Every time a read sequence begins, it starts by recording the readPositionExternalResetCount. When the reading has finished and read position is about to be updated, it verifies no external reset has been done by verifying the readPositionExternalResetCount was not increased relative to the recorded value. If it has, this means a reset action has started, which means we can drop and stop the reading sequence we have started. If not, no reset was done, continue and update read position.
Please note even this is not transactional and fully safe.

What do I suggest:

1. Rename variable. Epoch in computer science is mostly for how many seconds has passed since 1970-01-01. See https://en.wikipedia.org/wiki/Epoch_(computing)
2. Checking count has increased and if not update read position is not fully safe. Better guard update read position with a lock, since you're taking an action based on the count. I would take a lock on read position, and in that lock update count if needed and read position if needed.
3. I wouldn't use an exception for flow control. It's an expensive operation, especially for latency sensitive systems. Return value like Result of some sort - can we do that?

Tell me if I'm correct

Correct.

Rename variable. Epoch in computer science is mostly for how many seconds have passed since 1970-01-01. See https://en.wikipedia.org/wiki/Epoch_(computing)

Pulsar and Zookeeper have similar concepts named epoch, so epoch may be easier to understand? I have also corrected the document: epoch is also related to the change of mark deleted position(in other words, if the mark deleted position is changed by Cursor Reset, the epoch also increases)

Checking count has increased and if not update read position is not fully safe. Better guard update read position with a lock, since you're taking an action based on the count. I would take a lock on read position, and in that lock update count if needed and read position if needed.

Yes, this is consistent with the current design, the original document may not be clearly enough, I improved it

I wouldn't use an exception for flow control. It's an expensive operation, especially for latency sensitive systems. Return value like Result of some sort - can we do that?

Good suggestion, already instead of return -1.

Pulsar and Zookeeper have similar concepts named epoch, so epoch may be easier to understand? I have also corrected the document: epoch is also related to the change of mark deleted position(in other words, if the mark deleted position is changed by Cursor Reset, the epoch also increases)

ZK epoch seems more like a revision or version or sequence ID.
Given your explanation, it seems you need a revision/version/sequence ID for the state of the cursor state. How about cursorStateRevisionNum?

Revision is:

The act of changing or correcting something, or the thing that has been changed or corrected: [ U ] The Senate is expected to act on tax revision.

Good suggestion. already change this variable to cursorStateRevisionNum

Lost you here.
Why do you need to use same epoch.
I wonder why not a lock perhaps for cursor and dispatcher.
I guess I need to dive more perhaps.

Lost you here.

I have rewritten the doc to make it easier to understand.

Why do you need to use same epoch.

I could not fully understand this.

I wonder why not a lock perhaps for cursor and dispatcher.
I guess I need to dive more perhaps.

• The lock is better than synchronized because it is helpful for async logic.
• A lock and a variable is better than only a lock because they can help correct the task already in the queue of lock.
• Two locks (one for Cursor and one for Dispatcher) can make the lock range smaller. For example:
  • lock(Cursor), set resetting to true, release lock(Cursor). Other actions will be rejected by resetting in progress(fast fail).
  • lock(Dispatcher), do itself progress.

Since there is more than one component called Cursor Position Reset(see the section Cursor Position Reset, I have rewritten it), we can't make the lock too wide, it would increase the risk of deadlock.

Please, let's not add more code to ManagedCursorImpl - it becomes a dumpster.
Let's try to concentrate the same domain into one class.
First, I need to understand the high level design of goal 2 to be able to give good suggestions here.

Good suggestion. already added a new component CursorEpoch.java