apache/pulsar

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

Open

#6.847 aberto em 29 de abr. de 2020

Ver no GitHub
 (10 comments) (0 reactions) (0 assignees)Java (3.485 forks)batch import
help wantedlifecycle/staletype/bug

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

  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

Guia do colaborador