Uploaded image for project: 'Kafka'
  1. Kafka
  2. KAFKA-15221

Potential race condition between requests from rebooted followers

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Blocker
    • Resolution: Fixed
    • 3.5.0
    • 3.7.0
    • None
    • None

    Description

      When the leader processes the fetch request, it does not acquire locks when updating the replica fetch state. Then there can be a race between the fetch requests from a rebooted follower.

      T0, broker 1 sends a fetch to broker 0(leader). At the moment, broker 1 is not in ISR.

      T1, broker 1 crashes.

      T2 broker 1 is back online and receives a new broker epoch. Also, it sends a new Fetch request.

      T3 broker 0 receives the old fetch requests and decides to expand the ISR.

      T4 Right before broker 0 starts to fill the AlterPartitoin request, the new fetch request comes in and overwrites the fetch state. Then broker 0 uses the new broker epoch on the AlterPartition request.

      In this way, the AlterPartition request can get around KIP-903 and wrongly update the ISR.

      Attachments

        Issue Links

          Activity

            People

              calvinliu Calvin Liu
              calvinliu Calvin Liu
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: