[ https://issues.apache.org/jira/browse/AMQ-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743370#comment-16743370 ]
Christopher L. Shannon commented on AMQ-7132: --------------------------------------------- I am running Java 8 and so is Jenkins. All 3 tests hang for me running on the latest Fedora (just like Jenkins) It hangs from me both from Eclipse and from Maven. I'll take a look at it tomorrow closer. > 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: Improvement > Components: KahaDB > Affects Versions: 5.15.8 > Reporter: Alan Protasio > Assignee: Christopher L. Shannon > Priority: Major > Fix For: 5.16.0 > > > 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)