You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Mickael Maison (Jira)" <ji...@apache.org> on 2023/02/14 14:28:00 UTC

[jira] [Assigned] (KAFKA-14225) lazy val exemptSensor Could Cause Deadlock

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

Mickael Maison reassigned KAFKA-14225:
--------------------------------------

    Assignee: Huilin Shi

> lazy val exemptSensor Could Cause Deadlock
> ------------------------------------------
>
>                 Key: KAFKA-14225
>                 URL: https://issues.apache.org/jira/browse/KAFKA-14225
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.5.1
>            Reporter: Huilin Shi
>            Assignee: Huilin Shi
>            Priority: Blocker
>             Fix For: 3.4.0, 3.3.2
>
>
> There is a chance to cause deadlock when multiple threads access ClientRequestQuotaManager.
> In the version of Scala 2.12, the lazy val initialization is under the object lock. The deadlock could happen in the following condition:
> In thread a, when ClientRequestQuotaManager.exemptSensor is being initialized, it has acquired the object lock and enters the the actual initialization block. The initialization of 'exemptSensor' requires another lock private val lock = new ReentrantReadWriteLock() and it is waiting for this lock.
> In thread b, at the same time, ClientQuotaManager.updateQuota() is called and it has already acquired ReentrantReadWriteLock lock by calling lock.writeLock().lock(). And then it executes info(). If this is the first time accessing Logging.logger, which is also a lazy val, it need to wait for the object lock.
> Deadlock happens.
> Since the lazy val initialization is under the object lock, we should avoid using lazy val if the initialization function holds another lock to prevent holding two locks at the same time which is prone for deadlock. 



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