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 2018/07/20 19:08:00 UTC
[jira] [Commented] (AMQ-7016) Deadlock in KahaDB journal caused
during rotation and getting current data file
[ 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)