[
https://issues.apache.org/jira/browse/AMQ-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559757#comment-16559757
]
Gary Tully commented on AMQ-7015:
---------------------------------
unlike ignoreMissingJournalfiles/checkForCorruptJournalFiles leaving this on
for a running broker is broken, technically! I can't add any more to the
discussion. The mbean OOM is a bug.
But i am not going to -1 this, do what you must but I would tackle this
differently, possibly with some command line tool that flies through the
journal. I know there is more work to doing that and it would not be a quick
fix.
> 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)
