Version 1.14.0 has two new features to reduce locks caused by setting retained messages and therefore improving latency of the system. They are off by default as to not change behavior of existing installations.
They are:
- Defer/retry setting of retained messages when the lock can’t be obtained.
- Add ability to delay deletion of empty nodes in the retained messages tree, to avoid the later need for recreation which requires a write lock.
When setting a retained message on a topic for the first time, it requires a write lock on the tree to create this entry. If you have a lot of retained messages, this may cause too much contention between threads. FlashMQ can now requeue the action of setting the retained message asynchronously when it can’t obtain the lock immediately. This will keep the threads moving and latency low. The settings set_retained_message_defer_timeout and set_retained_message_defer_timeout_spread have been added to control how long it will attempt this before falling back to locking mode.
The second feature is controlled by the setting retained_message_node_lifetime. When you have retained messages that are set and deleted many times, you can make FlashMQ’s internal tree maintenance postpone deletion of the nodes, which will avoid the future need for a write lock to create it again.