kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Stopford (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-5036) Followups from KIP-101
Date Mon, 10 Apr 2017 13:08:42 GMT

    [ https://issues.apache.org/jira/browse/KAFKA-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962827#comment-15962827
] 

Ben Stopford commented on KAFKA-5036:
-------------------------------------

Points 2, 5 are addressed in PR: https://github.com/apache/kafka/pull/2831
Point 3 is addressed in PR: https://github.com/apache/kafka/pull/2821 (now merged)
Point 4 is an issue only in the test. The LogTest sets up a Log with an empty epoch cache.
Not addressed at this time.  

> Followups from KIP-101
> ----------------------
>
>                 Key: KAFKA-5036
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5036
>             Project: Kafka
>          Issue Type: Improvement
>    Affects Versions: 0.11.0.0
>            Reporter: Jun Rao
>            Assignee: Jun Rao
>             Fix For: 0.11.0.0
>
>
> 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:
> {code}
>        if (cachedLatestEpoch == None) error("Attempt to assign log end offset to epoch
before epoch has been set. This should never happen.")
> {code}
> 5. The constructor of LeaderEpochFileCache has the following:
> {code}
> lock synchronized { ListBuffer(checkpoint.read(): _*) }
> {code}
> But everywhere else uses a read or write lock. We should use consistent locking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message