apache/pulsar

Reader skips over large block of messages after calling `seek`

Open

#6847 aperta il 29 apr 2020

Vedi su GitHub
 (10 commenti) (0 reazioni) (0 assegnatari)Java (3485 fork)batch import
help wantedlifecycle/staletype/bug

Metriche repository

Star
 (13.697 star)
Metriche merge PR
 (Merge medio 3g 10h) (146 PR mergiate in 30 g)

Descrizione

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

  1. Publish to a topic for a while; high volume might help; e.g., tens of millions of messages at least
  2. Choose two timestamps, t1 and t2, with a decent window between them, that are both within the publishTimestamp history for the topic
  3. Do the following dozens of times
    1. Create a reader and call .seek(t1)
    2. Read initial messages until you get one in between t1 and t2 (I would think the first message should qualify, but often it doesn't, and I don't know why)
    3. Read and count messages until you see one with a publishTimestamp > t2
    4. Print/return the count
  4. 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

Guida contributor