lhotari commented on PR #23803: URL: https://github.com/apache/pulsar/pull/23803#issuecomment-2610019506
> * It may lead E2E latency increases There would be an opposite impact when handled correctly. When there's a race between a pending read and a replay read, either one will be discarded. This is why extra work is performed and that leads to increased latencies eventually since unnecessary reads are performed. There's currently no broker side caching for replay reads, so discarded replay reads will cause extra traffic between broker and bookies. To avoid the extra latency, when the pending read gets cancelled and once the replay read is complete, a new pending read should be issued so that new entries get handled immediately when they are available. I'll be doing this type of change to address #23845, which is one of the issues where a read doesn't continue when a read gets skipped. > * The pending normal read will be looped to `set` and `cancel` > * It may be a conflict with the feature `read ahead before all messages sent are acknowledged` Please explain more about these items since I didn't catch the meaning. > * (Highlight) your solution can not solve the issue that this PR solves, see more detail at Motivation When I made the comment, there was no description for this PR, so I'll check the updated description. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
