[
https://issues.apache.org/jira/browse/AMQ-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-3806.
-----------------------------
Resolution: Fixed
fix in http://svn.apache.org/viewvc?rev=1325810&view=rev
the location index, on which the size is based is the index of reference so
there is no point iterating if there are no messages. Why the orderindex still
has some data is an unknown at this point in this scenario, possibly a partial
index update/write.
> Partial index updates can lead to bogus recovery for the vmcursor of a Q on
> startup
> -----------------------------------------------------------------------------------
>
> Key: AMQ-3806
> URL: https://issues.apache.org/jira/browse/AMQ-3806
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Message Store
> Affects Versions: 5.5.1
> Reporter: Gary Tully
> Assignee: Gary Tully
> Fix For: 5.6.0
>
>
> seeing{code} INFO | Using Persistence Adapter:
> org.apache.activemq.store.kahadb.KahaDBStore@49f10a67
> INFO | KahaDB is version 4
> INFO | Recovering from the journal ...
> INFO | Recovery replayed 1 operations from the journal in 0.063 seconds.
> INFO | ActiveMQ 5.5.1 JMS Message Broker (..) is starting
> INFO | For help or more information please see: http://activemq.apache.org/
> INFO | cursor for queue://JMS/XXXXX has recovered 10000 messages. 2147483647%
> complete
> INFO | cursor for queue://JMS/XXXXX has recovered 20000 messages. 2147483647%
> complete{code}
> The crazy % is the result of recovering on a store that has 0 messages. The
> orderIndex seems to still allow iteration (possibly part of a partial index
> update) and can result in recovering for ever.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
