[
https://issues.apache.org/jira/browse/KAFKA-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723236#comment-16723236
]
Dong Lin commented on KAFKA-7297:
---------------------------------
[~ijuma] Hmm.. I think we may have different understanding. Jun originally does
mention the use of materialized view (which involves copying) to resolve the
underlying map may be changed. In the latest discussion, we agree that it is OK
for the underlying view because ConcurrentSkipListMap supports weak consistency.
So what we are trying to address in this ticket is the issue in the JIRA
description, i.e. additional entry may be returned by `Log.logSegments `. There
are two solutions to solve this problem. One solution is to use the atomic
update which involves extra copy for write operation. The other solution is the
use read/write lock which requires lock for read operation but there is no need
to copy for read/write operation. Is this understanding correct?
> 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)
