[ https://issues.apache.org/jira/browse/AMQ-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16555882#comment-16555882 ]
Jeff Genender commented on AMQ-7015: ------------------------------------ Hi Gary, Patch appears to be a stop gap way to purge all prepared transactions that are stuck in recovery. There is an mbean that allows full commit/rollback which is awesome. But for large amounts of XA stuck in prepare, the mbean can be unwieldy and users need a quick way to clean them out otherwise a slow recovery is kicked off on every restart. This is a switch that allows the XA messages to be purged from recovery in one shot. Its a switch and its off by default. Its a convenience setting. Let us know your thoughts on that. > 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)