You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Lan Ding (Jira)" <ji...@apache.org> on 2023/07/06 13:52:00 UTC

[jira] [Assigned] (KAFKA-15154) Potential bug: We don't acquire lock when reading checkQuotas

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

Lan Ding reassigned KAFKA-15154:
--------------------------------

    Assignee: Lan Ding

> Potential bug: We don't acquire lock when reading checkQuotas
> -------------------------------------------------------------
>
>                 Key: KAFKA-15154
>                 URL: https://issues.apache.org/jira/browse/KAFKA-15154
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Divij Vaidya
>            Assignee: Lan Ding
>            Priority: Major
>              Labels: newbie
>
> At sensor.java line:254, we call `this.metrics.values()`. metrics is not a thread safe map and that is why we acquire a lock whenever we want to add/remove entries from it. For example, see add(), hasMetrics() method.
> However, we don't acquire a lock when calling Sensor#checkQuotas(timeMs).
> This could lead to a situation where this metrics map may be left in an inconsistent state (since it is not thread safe for concurrent read/write access).
> The objective of this task is to validate what I said above is correct and if yes, then fix the situation by enclosing this read in a lock. As a stretch task, we should consider if we can replace the metrics data structure which allows concurrent reads but exclusive writes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)