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

Christopher L. Shannon updated AMQ-9202:
----------------------------------------
    Description: 
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. 
More info: 
https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern

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.

  was:
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.


> 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
>            Priority: Major
>             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. More info: 
> https://stackoverflow.com/questions/31058681/java-locking-structure-best-pattern
> 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)

Reply via email to