A-MQ 7 -- not enough synchronous disk writes to guarantee data integrity on openwire

When producing successive, persistent messages to a JMS destination in a single thread, the client it entitled to assume that if the send() operation returns without error, the message data has been made persistent by the broker – it is not just in memory.

With NIO journalling, Artemis updates the journal by using (or, rather, asking the JVM to use) a write() followed by an fdatasync(). By default, ActiveMQ uses a write() followed by fsync() (although it can be configured to use fdatasync() instead).

With ActiveMQ, I see almost exactly one sync update per message produced, as I would expected. With Artemis, I see a variable number, even when setting journal-max-io to 1.

It seems that Artemis (with NIO) does not guarantee that message data has been flushed to disk before the client gets a successful acknowledgment. With a moderately fast disk, and a fast message producer, there seem to be far fewer sync writes than messages. This is consistent with a flushing behaviour that is time-based, not message-volume based.