Details
-
Bug
-
Resolution: Done
-
Major
-
A-MQ 7.0.0.ER12
-
None
-
None
Description
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.