[ https://issues.apache.org/jira/browse/AMQ-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559829#comment-16559829 ]
Christopher L. Shannon commented on AMQ-7015: --------------------------------------------- I was going to stay out of it but seriously Jeff? There is community support? There are 4 responses on that thread and all of the people work for you and the same company. That's not community support, that is a single vendor solving a problem for one customer they have. I'm not saying that I agree or disagree with the issue (i'm more or less +0 on this feature) but I take offense when you claim that's community support when you know it isn't. Furthermore, Gary specifically said that he won't -1 this issue. > Startup performance improvement when log contains prepared transactions. > ------------------------------------------------------------------------ > > Key: AMQ-7015 > URL: https://issues.apache.org/jira/browse/AMQ-7015 > Project: ActiveMQ > Issue Type: New Feature > Affects Versions: 5.15.4 > Reporter: Heath Kesler > Assignee: Jeff Genender > Priority: Minor > Fix For: 5.16.0, 5.15.5 > > > I have a KahaDB that's performing a recovery on each startup. > Digging deeper into it I've found that the issue is that the db.log contains > prepared transactions. > The MessageDatabase will discard those entries in memory, however it does not > remove transaction info from those messages (I believe that's by design). So > on each restart, the broker will find those entries and again discard them in > memory. > If I access the broker via JMX, I can go to the prepared XAs and execute a > clear on them one by one. > When i restart my broker, i don't have a recovery attempted again. > Performing a remove operation for each message can be very time consuming, so > i'd like to introduce an optional parameter to allow all prepared XAs to be > removed on recovery. > Please see my forth coming patch with unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)