You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Christopher L. Shannon (Jira)" <ji...@apache.org> on 2023/02/01 16:13:00 UTC

[jira] [Created] (AMQ-9202) Reentrant locks should always be locked outside of a try block

Christopher L. Shannon created AMQ-9202:
-------------------------------------------

             Summary: Reentrant locks should always be locked outside of a try block
                 Key: AMQ-9202
                 URL: https://issues.apache.org/jira/browse/AMQ-9202
             Project: ActiveMQ
          Issue Type: Bug
    Affects Versions: 5.17.3
            Reporter: Christopher L. Shannon
            Assignee: Christopher L. Shannon
             Fix For: 5.18.0, 5.17.4


I saw an exception happen today that turned out to be improper use of Reentrant locks. Acquiring the lock should always be done before the try block so that the finally clause to unlock will never execute unless the lock is acquired.

The issue is inside of AbstractRuntimeConfigurationBroker, for example: [https://github.com/apache/activemq/blob/d8ce1d9ff0fa2296f3c56b59602e5cddb6ffe4a9/activemq-runtime-config/src/main/java/org/apache/activemq/plugin/AbstractRuntimeConfigurationBroker.java#L81]

I saw a IllegalMonitorStateException exception occur due to lockInterruptibly() throwing an exception so when the finally block tried to unlock it threw the IllegalMonitorStateException since it was not owned by the thread.

I went through the rest of the code and most places are correct but a couple spots need to be fixed as well.



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