Hi all,
An update on PIP-482, and a request for review so it can move toward a vote.
Based on review feedback, I've revised the API approach from my original
email:
- Original proposal: make the position-aware 6-arg peekMessages(...,
messagePosition, ...) the new abstract method, and demote the existing
overloads to default.
- Revised proposal: leave the existing peekMessages(..., numMessages,
showServerMarker, isolation) abstract method (and its async form)
unchanged, and add the position-aware capability as a new default overload.
Why: the revised approach adds, changes, and removes no abstract method, so
it's strictly additive and fully source- and binary-compatible — existing
Topics implementors and mocks are unaffected. The new default delegates to
the existing method when messagePosition == 1 (identical head-of-backlog
behavior) and throws UnsupportedOperationException otherwise; the in-tree
TopicsImpl overrides it to support arbitrary positions. I've also added an
end-to-end test that peeks page 1 then page 2 and asserts the second call
starts at the requested offset without re-reading the first page.
New API surface (the additive overload):
default List<Message<byte[]>> peekMessages(
String topic, String subName, int messagePosition, int numMessages,
boolean showServerMarker, TransactionIsolationLevel
transactionIsolationLevel)
throws PulsarAdminException;
The parameter is named messagePosition and typed int to mirror the REST
path param (.../position/{messagePosition}); happy to switch to a dedicated
type if preferred.
PIP:
https://github.com/Pruthvirajj240/pulsar/blob/pip-482-peek-messageposition/pip/pip-482.md
PR: https://github.com/apache/pulsar/pull/25911
I'd appreciate a review — particularly from a PMC member — so this can
proceed to a [VOTE]. Happy to address any concerns on the API shape,
naming, or compatibility.
Thanks,
Pruthviraj
