Control message persistence
Maintain messages in broker memory instead of persisting them in broker storage significantly improves broker performance.
There’s a small risk without message persistence that when the broker crashes, messages would get lost. However, this option is still widely used in the following scenarios:
a. If messages are not critical.
b. If messages can be easily recovered from producer side.
It should be avoided when messages are critical and not easy to reproduce.
Besides, it should also be avoided when broker performance is not the bottle neck. In many cases, performance bottle neck usually lies in message consumers or producers.
It can be set from the producer side when connecting to the broker queue, as a connection parameter. Normally it’s done per queue. It can also be done on a broker level, but that’s not recommended.
Control message acknowledge mode
Every enqueue option has an acknowledge mode. By default, it’s always “auto”, which means producers always wait for the response of the broker. The auto_ack guarantees the “once-and-only-once” delivery.
An alternative is “dup_ok” mode, using which producers will resend the message when the broker acknowledgement is not delivered in time or get lost. This could happen when huge amount of messages are processed by the broker. The dup_ok_ack mode guarantees “at-least-once” delivery. It’s used when there’s the need to quickly free up system resources on producer side and there’s logic built in the broker or consumer side to ignore duplicate messages.
It can be set from the producer side when creating connections to the broker queue.
Control message communication pattern
By default, ActiveMQ uses asynchronous message delivery. However, when the client has specific setting regarding synchronous message delivery, the async way of communication would be overridden. So it’s wise to check the settings on biztalk and outm side. The communication pattern is set per broker connection.