Search before asking
Motivation
The Pulsar admin REST endpoint
/admin/v3/persistent/{tenant}/{namespace}/{topic}/subscription/{subName}/position/{messagePosition}
accepts an arbitrary message position. The Java admin client (Topics.peekMessages and peekMessagesAsync) currently hardcodes position 1, so callers can only peek from the head of the backlog.
The common use case affected is paginated display in admin UIs — to show the 91st–100th unacknowledged messages, callers have to fetch and discard the first 90, which is wasteful in bandwidth, memory, and time on both client and broker.
Solution
Add a messagePosition parameter to Topics.peekMessages and Topics.peekMessagesAsync in the Java admin client.
The new primary method signature:
List<Message<byte[]>> peekMessages(String topic, String subName,
int messagePosition, int numMessages,
boolean showServerMarker, TransactionIsolationLevel transactionIsolationLevel)
throws PulsarAdminException;
All pre-existing peek overloads become default methods delegating to this primary, preserving source and binary compatibility.
Full design and compatibility analysis is captured in PIP-482:
Alternatives
Two alternatives considered and discussed in the PIP under "Alternatives Considered":
MessageId-based peek — more powerful but requires server-side changes; deferred to a future PIP.
PeekOptions builder — more extensible but a larger API redesign; deferred to a future PIP.
Anything else?
No response
Are you willing to submit a PR?
Search before asking
Motivation
The Pulsar admin REST endpoint
/admin/v3/persistent/{tenant}/{namespace}/{topic}/subscription/{subName}/position/{messagePosition}accepts an arbitrary message position. The Java admin client (
Topics.peekMessagesandpeekMessagesAsync) currently hardcodes position1, so callers can only peek from the head of the backlog.The common use case affected is paginated display in admin UIs — to show the 91st–100th unacknowledged messages, callers have to fetch and discard the first 90, which is wasteful in bandwidth, memory, and time on both client and broker.
Solution
Add a
messagePositionparameter toTopics.peekMessagesandTopics.peekMessagesAsyncin the Java admin client.The new primary method signature:
All pre-existing peek overloads become
defaultmethods delegating to this primary, preserving source and binary compatibility.Full design and compatibility analysis is captured in PIP-482:
Alternatives
Two alternatives considered and discussed in the PIP under "Alternatives Considered":
MessageId-based peek — more powerful but requires server-side changes; deferred to a future PIP.PeekOptionsbuilder — more extensible but a larger API redesign; deferred to a future PIP.Anything else?
No response
Are you willing to submit a PR?