You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Tim Bain (JIRA)" <ji...@apache.org> on 2018/03/18 06:15:00 UTC
[jira] [Updated] (AMQ-6931) KahaDB files cannot be loaded if they
contain KAHA_ACK_MESSAGE_FILE_MAP_COMMAND messages
[ https://issues.apache.org/jira/browse/AMQ-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Bain updated AMQ-6931:
--------------------------
Description:
As reported on the users mailing list ([http://activemq.2283324.n4.nabble.com/Re-failed-to-start-ActiveMQ-td4737631.html]), a KahaDB file that contains a message of type "CmdType: KAHA_ACK_MESSAGE_FILE_MAP_COMMAND" (output is from [https://github.com/Hill30/amq-kahadb-tool]) was found to have a location size of 0, which is less than org.apache.activemq.store.kahadb.disk.journal.Journal.RECORD_HEAD_SPACE. This in turn causes a NegativeArraySizeException to be thrown in org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord() when attempting to start the broker.
Either the data file should not have a location size of 0 (in which case, we need to figure out how it happened and prevent it from happening again), or it's valid to have a location size of 0 and we need to account for that possibility when constructing the array in readRecord().
One fact that may or may not be relevant: the file that contains the zero-size records is the most recent journal file in the data directory, and the persistence store had reached the store limit. It was not clear from the mailing list thread whether other files also had the problem, nor whether it would have occurred if the store limit had not been reached.
was:
As reported on the users mailing list (http://activemq.2283324.n4.nabble.com/Re-failed-to-start-ActiveMQ-td4737631.html), a KahaDB file that contains a message of type "CmdType: KAHA_ACK_MESSAGE_FILE_MAP_COMMAND" (output is from [https://github.com/Hill30/amq-kahadb-tool]) was found to have a location size of 0, which is less than org.apache.activemq.store.kahadb.disk.journal.Journal.RECORD_HEAD_SPACE. This in turn causes a NegativeArraySizeException to be thrown in org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord() when attempting to start the broker.
Either the data file should not have a location size of 0 (in which case, we need to figure out how it happened and prevent it from happening again), or it's valid to have a location size of 0 and we need to account for that possibility when constructing the array in readRecord().
> KahaDB files cannot be loaded if they contain KAHA_ACK_MESSAGE_FILE_MAP_COMMAND messages
> ----------------------------------------------------------------------------------------
>
> Key: AMQ-6931
> URL: https://issues.apache.org/jira/browse/AMQ-6931
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
> Affects Versions: 5.13.1
> Reporter: Tim Bain
> Priority: Major
>
> As reported on the users mailing list ([http://activemq.2283324.n4.nabble.com/Re-failed-to-start-ActiveMQ-td4737631.html]), a KahaDB file that contains a message of type "CmdType: KAHA_ACK_MESSAGE_FILE_MAP_COMMAND" (output is from [https://github.com/Hill30/amq-kahadb-tool]) was found to have a location size of 0, which is less than org.apache.activemq.store.kahadb.disk.journal.Journal.RECORD_HEAD_SPACE. This in turn causes a NegativeArraySizeException to be thrown in org.apache.activemq.store.kahadb.disk.journal.DataFileAccessor.readRecord() when attempting to start the broker.
> Either the data file should not have a location size of 0 (in which case, we need to figure out how it happened and prevent it from happening again), or it's valid to have a location size of 0 and we need to account for that possibility when constructing the array in readRecord().
> One fact that may or may not be relevant: the file that contains the zero-size records is the most recent journal file in the data directory, and the persistence store had reached the store limit. It was not clear from the mailing list thread whether other files also had the problem, nor whether it would have occurred if the store limit had not been reached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)