[jira] [Commented] (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:comment-tabpanel=16410961#comment-16410961 ] Rural Hunter commented on AMQ-6931: --- I jsut raised another issue: AMQ-6936, not sure if it is related to this one. > 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)
[jira] [Commented] (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:comment-tabpanel=16409018#comment-16409018 ] Tim Bain commented on AMQ-6931: --- [~gtully] The fix for AMQ-6815 doesn't handle the zero-length payload problem (it only looks for payloads that are larger than the total size of the file). Even if the changes under AMQ-6815 fix the cause of the corruption, it might still be worth adding a check for content that is shorter than the size of the header so we don't error out when reading a file that does get corrupted. > 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)
[jira] [Commented] (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:comment-tabpanel=16406183#comment-16406183 ] Gary Tully commented on AMQ-6931: - I think this is solved via: https://issues.apache.org/jira/browse/AMQ-6815 > 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)