[
https://issues.apache.org/jira/browse/KAFKA-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18042973#comment-18042973
]
Akram Khan commented on KAFKA-15154:
------------------------------------
Hi @isding_l, @divijvaidya, @mstepan — I’m interested in contributing to this
issue if it’s still active.
I wanted to check whether there is ongoing work here. If not, I’d be happy to
take it over.
My plan is to investigate the race in {{Sensor#checkQuotas()}} fully, review
the existing locking order (Sensor → metricLock), and evaluate safe options
such as synchronizing the read path, introducing a ReadWriteLock, or exploring
lock-free/atomic alternatives. I’ll also add a focused concurrency test to
reproduce the issue and validate the fix across the clients test suite.
Please let me know if this is still open for contribution. Thanks!
> 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
> Components: metrics
> 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)
