michalcukierman commented on code in PR #21170:
URL: https://github.com/apache/pulsar/pull/21170#discussion_r1325662008
##########
pulsar-client/src/main/java/org/apache/pulsar/client/impl/TableViewImpl.java:
##########
@@ -235,20 +238,33 @@ private CompletableFuture<Reader<T>>
readAllExistingMessages(Reader<T> reader) {
AtomicLong messagesRead = new AtomicLong();
CompletableFuture<Reader<T>> future = new CompletableFuture<>();
- readAllExistingMessages(reader, future, startTime, messagesRead);
+ reader.getLastMessageIdsAsync().thenAccept(lastMessageIds -> {
+ Optional<TopicMessageId> optionalTopicMessageId =
lastMessageIds.stream().max(Comparator.naturalOrder());
Review Comment:
Some things to concern:
First case: working on partitioned topics:
Imagine:
- `topic-partiton-1` - containing 1 million messages
- `topic-partition-2` - containing 1 message
When a producer writes a new message to topic-partition-2 and it gets to
TableView, the method will be stopped.
Second case: work with compaction
- After the compaction, if the new client connects, the messages read first
will have messageIds from the compacted ledger. Will compareTo work in that
case?
Third case:
- Comparison of MessageId when delivered in batches (this should probably be
OK now)
I think that the algorithm should store every last message from each
partition (first issue). Then the stop mechanism should be based on the exact
message delivery.
--
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]
