[
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)
