You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Prakash Saraf (JIRA)" <ji...@apache.org> on 2018/07/20 18:04:00 UTC

[jira] [Created] (AMQ-7016) Deadlock in KahaDB journal caused during rotation and getting current data file

Prakash Saraf created AMQ-7016:
----------------------------------

             Summary: 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
         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)