Ignoring flow control message when resetCursorInProgress=TRUE

[wenbingshen]

Describe the bug

1. Our broker is highly busy
   

2. Our business uses Reader for consumption, in which seek operations are often performed.

3. In the seek operation of pulsar, there will be a process of actively disconnecting the consumer and canceling the currently reading operation.

4. Next, whether the seek operation is completed or not, the client has the right to subscribe the subscription.

5. Because the server thread pool is busy, the seek operation is delayed. The client first subscribed a subscription and initiates a FLOW request, causing the broker to start reading data.

6. Next, the seek operation is completed, and the positions of md position and rd position are reset to the seek position.

7. Then, the read operation is completed, after the data is sent to the client, the client executes ack, and md and rd are set to a certain position of the message read by the client.

8. Next, the seek operation is completed, and the positions of md position and rd position are reset to the seek position.

9. Then, the read operation is completed, after the data is sent to the client, the client executes ack, and md and rd are set to a certain position of the message read by the client.

The entire execution flow is shown in the following figure:

[Jason918]

It will be better for others to understand this if you can emphasize which step is not expected and what final result you got.

[wenbingshen]

It will be better for others to understand this if you can emphasize which step is not expected and what final result you got.

Thanks for your replay. My expected result is: when my application finishes the seek operation, the first message read next must be the message where I seek.

But now unfortunately, in my cluster, before the seek operation is completed, the broker has started to read the data starting from the current position from the bookie, and after my seek operation is completed, this part of the data is returned to the client , but the client does not want to know whether the position of the data it reads matches where it seeks, because the client has only two steps: 1. Execute seek, 2. Read the data immediately after the seek is completed.

As shown in the figure below: The most important thing is to ensure the order of 5 and 6. It should be executed first for 5. The existing logic cannot guarantee this.

[codelipenghui]

Looks like a similar problem that https://github.com/apache/pulsar/wiki/PIP-84-:-Pulsar-client:-Redeliver-command-add-epoch want to resolve.

[wenbingshen]

Looks like a similar problem that https://github.com/apache/pulsar/wiki/PIP-84-:-Pulsar-client:-Redeliver-command-add-epoch want to resolve.

Thanks for your reply. It looks a bit similar, but the two are slightly different. PIP-84 seems to only emphasize the synchronization consistency of data retransmission and data pull, but has no details about the seek operation. If you mean adding an epoch to the seek operation, assuming that the epoch of the seek operation is 1, the broker will disconnect the client when the seek operation starts, and the epoch will be 2 when the client resubscribe the subscription again. The FLOW request at this time will cause the broker to start reading data and return it to the client. The client seems to have no way to filter out the data with epoch 2, and then the broker completes the seek operation with epoch 1.

[github-actions]

The issue had no activity for 30 days, mark with Stale label.

[github-actions]

The issue had no activity for 30 days, mark with Stale label.