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

Followups from KIP-101

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.11.0.0
    • Fix Version/s: 0.11.0.0
    • Component/s: None
    • Labels:
      None

      Description

      1. It would be safer to hold onto the leader lock in Partition while serving an OffsetForLeaderEpoch request.

      2. Currently, we update the leader epoch in epochCache after log append in the follower but before log append in the leader. It would be more consistent to always do this after log append. This also avoids issues related to failure in log append.

      3. OffsetsForLeaderEpochRequest/OffsetsForLeaderEpochResponse:
      The code that does grouping can probably be replaced by calling CollectionUtils.groupDataByTopic(). Done: https://github.com/apache/kafka/commit/359a68510801a22630a7af275c9935fb2d4c8dbf

      4. The following line in LeaderEpochFileCache is hit several times when LogTest is executed:

             if (cachedLatestEpoch == None) error("Attempt to assign log end offset to epoch before epoch has been set. This should never happen.")
      

      This should be an assert (with the tests fixed up)
      5. The constructor of LeaderEpochFileCache has the following:

      lock synchronized { ListBuffer(checkpoint.read(): _*) }
      

      But everywhere else uses a read or write lock. We should use consistent locking.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                benstopford Ben Stopford
                Reporter:
                junrao Jun Rao
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: