[
https://issues.apache.org/jira/browse/KAFKA-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722044#comment-16722044
]
Dong Lin commented on KAFKA-7297:
---------------------------------
[~junrao] After going through the code and the Java doc, it appears that
currently the only "correctness" concern due to this issue are 1)
Log.deleteRetentionSizeBreachedSegments() may delete segment that otherwise
would not be deleted and 2) ReplicaManager.describeLogDirs() and thus result in
the DescribeLogDirResponse may be larger than the actual value which causes
overestimation on the user side.
The probability of this happening is very rare and the impact of the
consequence seems low. I agree it may not be causing problem now.
Instead of documenting that the iterator may return overlapping segment, would
it be be better to fix the issue described in this JIRA so that we will not see
overlapping segment in the iterator? As you mentioned in the earlier comment,
since all callers of Log.logSegments seem to either be holding lock already or
is infrequent, the overhead seems OK, right?
> Both read/write access to Log.segments should be protected by lock
> ------------------------------------------------------------------
>
> Key: KAFKA-7297
> URL: https://issues.apache.org/jira/browse/KAFKA-7297
> Project: Kafka
> Issue Type: Improvement
> Reporter: Dong Lin
> Assignee: Zhanxiang (Patrick) Huang
> Priority: Major
>
> Log.replaceSegments() updates segments in two steps. It first adds new
> segments and then remove old segments. Though this operation is protected by
> a lock, other read access such as Log.logSegments does not grab lock and thus
> these methods may return an inconsistent view of the segments.
> As an example, say Log.replaceSegments() intends to replace segments [0,
> 100), [100, 200) with a new segment [0, 200). In this case if Log.logSegments
> is called right after the new segments are added, the method may return
> segments [0, 200), [100, 200) and messages in the range [100, 200) may be
> duplicated if caller choose to enumerate all messages in all segments
> returned by the method.
> The solution is probably to protect read/write access to Log.segments with
> read/write lock.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
