[
https://issues.apache.org/jira/browse/AMQ-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551149#comment-16551149
]
Christopher L. Shannon commented on AMQ-7016:
---------------------------------------------
This was fixed in version 5.14.3
> Deadlock in KahaDB journal caused during rotation and getting current data
> file
> --------------------------------------------------------------------------------
>
> Key: AMQ-7016
> URL: https://issues.apache.org/jira/browse/AMQ-7016
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
> Affects Versions: 5.14.0
> Environment: Apache AMQ 5.14.0 with Java Spring.
> Reporter: Prakash Saraf
> Priority: Major
> Attachments: amq_deadlock.log
>
>
> Hi,
> We encountered a deadlock in AMQ. From the thread analysis it looks the
> deadlock happened during one thread doing reservation of journal file
> (journal compaction thread), while other was getting the current data file
> (general data appender).
> *Thread 1 (any of thread that add/remove mesg):*
> The getCurrentDataFile(int capacity) method, first locks the currentDataFile
> and then does rotation, if current capacity is not enough. The
> rotateWriteFile first locks the fileId and then the current file.
> Locks in sequence -> currentDataFile -> dataFileIdlock -> currentDataFile
> *Thread 2:*
> The reserveDataFile method first locks dataFileIdlock and then
> currentDataFile.
> Locks in sequence -> dataFileIdlock -> currentDataFile
>
> Please also see the thread dumps attached.
> Shouldn't we always first lock the currentDataFile and then dataFildIdLock?
> Is there a potential reason, why the reserveDataFile and rotateWriteFile
> first locks fileId and then currentDataFile?
> Can we also consider using read/write locks rather complete object lock?
> Please let me know if any other details are required.
> Thanks,
> Prakash Saraf
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
