[
https://issues.apache.org/jira/browse/AMQ-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089822#comment-16089822
]
Christopher L. Shannon commented on AMQ-6771:
---------------------------------------------
[~gtully], Great work here, the slowness on startup when
checkForCorruptJournalFiles is enabled is something I've seen happen quite
often and has been quite annoying so I'm looking forward to testing this patch
out. It was something I was hoping to revisit at some point to improve but
never got around to it. In your testing how much faster is the new scan on
startup compared to the old way?
> Improve performance of KahaDB recovery check checkForCorruptJournalFiles=true
> -----------------------------------------------------------------------------
>
> Key: AMQ-6771
> URL: https://issues.apache.org/jira/browse/AMQ-6771
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
> Affects Versions: 5.15.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Fix For: 5.16.0
>
>
> The KahaDB checkForCorruptJournalFiles option validates the checksum of every
> journal batch record on startup. If a single producer writes many small
> messages, the batch sizes in the journal will be small. The current check
> implementation reads each batch at a time with a fseek/read sequence that can
> be very slow over shared disks.
> The check can be a quick buffered sequential read using the maxBatchSize
> which should already be tuned to match the disk transfer rate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
