activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Tuning activemq for reliability, not performance
Date Tue, 08 Oct 2013 14:22:21 GMT
yes this is possible and should be the norm.

What version are you using and what persistence adapter?
How are messages acknowledged?
seems like you may be using optimizeAcknowledge mode?

some pointers:

use kahadb - concurrentStoreAndDispatchQueues=false - dispatch after
persistence, enableJournalDiskSync=true (default mode) to force a disk
use persistent messages and alwaysSyncSend on your client. So sends
only complete when the message is on disk.
use transacted sessions in your consumers so that you have guarantees
around message acknowledgement, again forcing a disk sync on commit.

Do your disks support fsync?

On 8 October 2013 13:18, Graham Leggett <> wrote:
> Hi all,
> We have a system that does heavy message processing where we have very few (tens, hundreds)
of messages that take minutes to process each.
> What we also have is periodic activemq v5.8.0 instability that causes the "java service
wrapper" to proactively send a "kill -9" signal to the activemq process. This reverts the
queue state right back to where the queue was started, and long since processed messages suddenly
come back, triggering a very expensive message re-processing exercise.
> What we want to do is ensure that all memory caching in activemq is switched off completely,
and all changes are written through to disk at all times. We don't care about the performance
implications, reliability is our number one requirement. If activemq leaks, crashes, we want
the most recent state practical preserved.
> Is this possible?
> Regards,
> Graham
> --


View raw message