Denovo1998 commented on PR #4772: URL: https://github.com/apache/bookkeeper/pull/4772#issuecomment-4515643233
@hangc0276 I agree that delayed-message delivery alone may not be common enough to justify protocol complexity. But the proposed option is not specific to delayed messages. It is a generic per-read access-pattern hint for point-read/probe-read workloads. BookKeeper read-ahead is very useful for sequential catch-up reads, backlog consumption, and ledger scans. The problem is that some Pulsar/KoP read paths are not sequential streams. They use BookKeeper entries as lookup probes or sparse snapshot segments. In these cases, prefetching N+1/N+2 can have low hit rate and can pollute the read-ahead cache used by normal sequential readers. Examples: 1. BucketDelayedDeliveryTracker snapshot segment lazy loading. 2. KoP FETCH/ListOffsets/seek path, where a Kafka offset must be mapped to a Pulsar MessageId before normal reading. 3. BrokerEntryMetadata.index based position lookup, where entries are read as index probes, potentially with binary-search-like access patterns. So the intent is not to optimize a rare delayed-message path, but to let callers distinguish sequential data reads from point lookup reads while keeping read-ahead as the default behavior. -- 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]
