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

Should consider commit latency when computing next commit timestamp

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.6.0
    • Fix Version/s: 2.7.0, 2.6.1
    • Component/s: streams
    • Labels:
      None

      Description

      In 2.6, we reworked the main processing/commit loop in `StreamThread` and introduced a regression, by not updating the current time after committing. This implies that we compute the next commit timestamp too low (ie, too early).

      For small commit intervals and high commit latency (like in EOS), this big may lead to an increased commit frequency and fewer processed records between two commits, and thus to reduced throughput.

      For example, assume that the commit interval is 100ms and the commit latency is 50ms, and we start the commit at timestamp 10000. The commit finishes at 10050, and the next commit should happen at 10150. However, if we don't update the current timestamp, we incorrectly compute the next commit time as 10100, ie, 50ms too early, and we have only 50ms to process data instead of the intended 100ms.

      In the worst case, if the commit latency is larger than the commit interval, it would imply that we commit after processing a single record per task.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mjsax Matthias J. Sax
                Reporter:
                mjsax Matthias J. Sax
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: