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 sync. 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 <minf...@sharp.fm> 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 > -- > -- http://redhat.com http://blog.garytully.com
