With the Artemis client, non-persistent messages are delivered asynchronously to the A-MQ 7 broker. While this improves throughput, it increases the risk of messages being lost without the client noticing. There is a blockOnNonDurableSend configuration option which can be set to "true" to make the message delivery synchronous, so the client will be aware of the failure. The problem is that A-MQ administrators have no particular reason to set this option.

With non-persistent messaging, there will always be a non-zero risk of messages being lost without the client noticing. However, in most cases message loss will be associated with an evident failure – a crash of the broker or loss of the storage provider, for example. The default asynchronous behaviour, however, raises the prospect of messages being lost in non-failure situations, where the administrator would be unaware that there was any need to take action.

The example that led to this bug being raised was a misconfiguration in the authorization settings. Messages could not be delivered because the authorization settings were incorrect, but this went unnoticed from some time. While this is, to some extent, an avoidable failure, I am concerned that there are other situations that could lead to the same problem, that aren't directly attributable to an administrative oversight – storage exhausted, for example.

Other message brokers don't necessarily treat persistent and non-persistent messages differently as regards error handling, so customers migrating from a different broker could introduce a problem of which they are unaware.

In general, however, an enterprise product really ought to default to the most reliable operation, rather than the operation that provides the best throughput, if there is a conflict.