[ https://issues.apache.org/jira/browse/AMQ-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740664#comment-16740664 ]
Alan Protasio commented on AMQ-7132: ------------------------------------ Hi. I've updated PR with the KahaDBVersionTest to test the migration from kahadb 6 to 7. [~cshannon] I can definitely do the same thing that I did with MessageStoreStatistics with the MessageStoreSubscriptionStatistics and keep this information also in the index. But i would do it in another PR to keep the PRs as understandable and simple as possible. What do you think? > ActiveMQ reads lots of index pages upon startup (after a graceful or > ungraceful shutdown) > ----------------------------------------------------------------------------------------- > > Key: AMQ-7132 > URL: https://issues.apache.org/jira/browse/AMQ-7132 > Project: ActiveMQ > Issue Type: Test > Components: KahaDB > Affects Versions: 5.15.8 > Reporter: Alan Protasio > Priority: Major > Fix For: 5.16.0, 5.15.9 > > > Hi. > We noticed that ActiveMQ reads lots of pages in the index file when is > starting up to recover the destinations statistics: > [https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/KahaDBStore.java#L819] > Nowadays, in order to do that, activemq traverse the > storedDestination.locationIndex to get the messageCount and totalMessageSize > of each destination. For destinations with lots of messages this process can > take a while making the startup process take long time. > In a case of a master-slave broker, this prevent the broker to fast failover > and does not meet what is stated on > [http://activemq.apache.org/shared-file-system-master-slave.html.] > {quote}If you have a SAN or shared file system it can be used to provide > _high availability_ such that if a broker is killed, another broker can take > over immediately. > {quote} > One solution for this is keep track of the destination statistics summary in > the index file and doing so, we dont need to read all the locationIndex on > the start up. > The code change proposed is backward compatible but need a bump on the kahadb > version. If this information is not in the index, the broker will fall back > to the current implementation, which means that the first time people upgrade > to the new version, it will still have to read the locationIndex, but > subsequent restarts will be fast. > This change should have a negligible performance impact during normal > activemq operation, as this change introduce a few more bytes of data to the > index and this information will be on checkpoints. Also, this new information > is synchronized with the locationIndex as they are update at the same > transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)