[
https://issues.apache.org/jira/browse/KAFKA-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720710#comment-16720710
]
Jun Rao commented on KAFKA-7297:
--------------------------------
To follow up on that, another related issue is that currently, we are just
returning a view from Log.logSegments. Even if we hold the lock there, when the
caller iterates it, the iterated view is still undefined when the backing map
is changing. So, it seems that Log.logSegments needs to hold the lock and
return a materialized iterator (using iterable.toBuffer). All callers of
Log.logSegments seem to either be holding lock already or is infrequent. So,
the added toBuffer overhead is likely ok.
[~lindong]: Do you still plan to work on that?
> 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: Dong Lin
> 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)
