[ https://issues.apache.org/jira/browse/KAFKA-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722342#comment-16722342 ]
Ismael Juma commented on KAFKA-7297: ------------------------------------ Another way to handle this is for mutating operations to update a copy and then atomically update the collection. That's generally a better pattern when mutations are rare compared to reads. > 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)