It'll only throw away unconsumed messages. So a single event like a whole-house power failure won't lose many messages, because the consumer will probably be up to date and there won't be any messages on the broker. You're only at risk of data loss if there are multiple failures separated by a significant amount of time (the consumer dies, and then substantially later the broker dies due to something unrelated). It might be that the odds of that are low enough and the consequences reasonable enough that you can accept that risk, or maybe not.
Also, keep in mind that if you're keeping data in memory until you fill memory, your messages are non-persistent and will be lost when the message broker cycles. That's true for any messaging product configured the way you've said you want it, so it's not unique to ActiveMQ 5.x. If losing most or all of your unconsumed messages is a problem, you need to be storing them on disk even if it wears out your cheap SSDs, or you need to stand up a central broker on something with an attached spinning disk. Tim On Jan 26, 2018 10:51 AM, "Noel Grandin" <noelgran...@gmail.com> wrote: On Fri, 26 Jan 2018 at 19:22, Tim Bain <tb...@alumni.duke.edu> wrote: > > 5.x can also do in-memory-till-full-then-spool-to-disk when using > non-persistent messages (which go to the memory store and then to the temp > store if the memory store is full). > That’s useful info thanks. But non persistent means that the broker will throw away the messages on a reboot? Which wouldn’t be good for me. I can lose a small window of data, but if the wan disconnects for a while and then the machine reboots I need to keep most of the data. >
