[
https://issues.apache.org/jira/browse/AMQ-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Smith updated AMQ-6134:
----------------------------
Attachment: activemq.xml
For posterity, attaching the activemq.xml we use.
Since we are (currently) pre 5.12, the options you mention are not available,
We wouldn't want to have ActiveMQ try to reduce it's disk usage as the disk
fills up, because based on our experience it will just reduce to 0, and then
become unresponsive still. So we're looking to define an effective
minimum/maximum disk space usage as the same, and claim the space. We have
calculated a disk space size that should hold up to 0.5 days worth of
production scale messages to be stored to allow for a reasonable period of
consumer down time and to allow flexibility in an incident response.
but just to make sure I get this right when we do the upgrade, is this what we
should do (based on the above attached activemq.xml)?
* enable 'checkForCorruptJournalFiles'
* set the 'preallocationStrategy' - though with what, the documentation at
http://activemq.apache.org/kahadb.html are the only valid options
['sparse_file', 'zeros', 'os_kernel_copy'] I would have chosen 'zeros' here
just to be sure (we're running Oracle Linux 6.x )
Is there any other suggestions to maximize uptime in this regards?
thanks heaps for the response.
> ActiveMQ corrupted state when local disk fills up and Queues begin to buffer
> to KahaDB
> --------------------------------------------------------------------------------------
>
> Key: AMQ-6134
> URL: https://issues.apache.org/jira/browse/AMQ-6134
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
> Affects Versions: 5.11.1
> Reporter: Paul Smith
> Priority: Critical
> Attachments: activemq.log, activemq.xml
>
>
> There are already issues reporting this in AMQ-3098 and AMQ-5786 but they
> have been closed as Incomplete, I've left a comment on 5786 but I fear that
> it may get lost.
> Fundamentally KahaDB & ActiveMQ do not survive if Queues start filling up and
> buffering to KahaDB disk when the disk then becomes full because of an
> external issue (in our case rsyslog).
> Because KahaDB does not pre-allocate space, it seems vunerable to this case.
> I will attach broker logs and Kahadb store during the corrupted state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
