How a setting reaches a running node verifiedcriticalWritten by the Hub
A MailerQ setting lives in the database and reaches a node one of two ways: quietly, when the node's cache expires, or at once, when someone publishes a reload message to the cluster exchange.
In detail
This is the single most important mechanism for anything that writes settings from the outside, and it is the reason a change can look lost. The engine holds every table in memory and refreshes on a timer (mq5.directive.database-ttl, ten minutes by default). The management console hides this by doing both halves: it writes the row and then publishes the control message, so its changes appear instantly. A program that writes the row and stops — which is what Hub would naturally do — gets a change that takes effect at an unpredictable moment up to ten minutes later, on each node separately. The control messages are two. {"reload": true} tells every node bound to the exchange to re-read the database; {"hello": true} asks nodes to announce themselves immediately instead of waiting for their next scheduled announcement. Both are plain JSON published to the fanout exchange, so anything that can talk to the broker can send them — no MailerQ API is involved.