You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Dong Lin (JIRA)" <ji...@apache.org> on 2018/12/14 03:24:00 UTC

[jira] [Assigned] (KAFKA-7297) Both read/write access to Log.segments should be protected by lock

     [ https://issues.apache.org/jira/browse/KAFKA-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dong Lin reassigned KAFKA-7297:
-------------------------------

    Assignee: Zhanxiang (Patrick) Huang  (was: Dong Lin)

> 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)