Reader skips over large block of messages after calling `seek`
#6.847 aberto em 29 de abr. de 2020
Métricas do repositório
- Stars
- (13.697 stars)
- Métricas de merge de PR
- (Mesclagem média 3d 10h) (146 fundiu PRs em 30d)
Description
Bug Description
In some difficult-to-reproduce circumstances, a reader will skip forward to later in the topic with no indication that anything abnormal happened.
To Reproduce
- Publish to a topic for a while; high volume might help; e.g., tens of millions of messages at least
- Choose two timestamps,
t1andt2, with a decent window between them, that are both within thepublishTimestamphistory for the topic - Do the following dozens of times
- Create a reader and call
.seek(t1) - Read initial messages until you get one in between
t1andt2(I would think the first message should qualify, but often it doesn't, and I don't know why) - Read and count messages until you see one with a
publishTimestamp > t2 - Print/return the count
- Create a reader and call
- Compare the results across runs
Expected behavior
The result should always be the same, assuming the publisher is setting publishTimestamp monotonically and has already passed t2 at the beginning of the test.
Additional context
I often see that during the run the consumer makes a large jump. Just recently I have noticed that the point it jumps to (the "jump target") increases over time, in a way that I think tracks the messages being published to the topic. I saw a very reliable increase until I stopped the producer, and then the increase stopped.
Configurations I've Tested
- Broker versions 2.4.2, 2.5.1
- Producer version 2.3.0, 2.5.1
- Just one producer at a time
- Non-partitioned topics
- Batching enabled
- Python client, but mostly Java client
- Both reader and consumer
- Tiered storage; I've observed the issue on timespans that precede, follow, and straddle the ledger offloading boundary, as well as topics that haven't been offloaded at all yet