@@ -266,3 +266,21 @@ end}.
266266
267267{mapping, "mqtt.durable_queue_type", "rabbitmq_mqtt.durable_queue_type",
268268 [{datatype, {enum, [classic, quorum]}}]}.
269+
270+ %% If feature flag rabbit_mqtt_qos0_queue is enabled, a pseudo queue of type rabbit_mqtt_qos0_queue is
271+ %% created for an MQTT "Clean Session" that subscribes with QoS 0. This queue type holds MQTT messages
272+ %% directly in the MQTT connection process mailbox. This queue type has no flow control which
273+ %% means MQTT messages might arrive faster in the Erlang mailbox than being sent to the subscribing MQTT
274+ %% client. To protect against high memory usage, RabbitMQ intentionally drops QoS 0 messages if both
275+ %% 1.) the number of messages in the MQTT connection process mailbox exceeds mailbox_soft_limit, and
276+ %% 2.) the socket sending to the MQTT client is busy (i.e. not sending fast enough).
277+ %% Note that there can be other messages in the mailbox (e.g. MQTT messages sent from the MQTT client to
278+ %% RabbitMQ or confirmations from another queue type to the MQTT connection process) which are
279+ %% obviously not dropped. However, these other messages also contribute to the `mailbox_soft_limit`.
280+ %% Setting mailbox_soft_limit to 0 disables the overload protection mechanism to drop QoS 0 messages.
281+ %% Setting mailbox_soft_limit to a very high value decreases the likelihood of intentionally dropping
282+ %% QoS 0 messages while increasing the risk of causing a cluster wide memory alarm.
283+ %%
284+ %% {mailbox_soft_limit, 30},
285+ {mapping, "mqtt.mailbox_soft_limit", "rabbitmq_mqtt.mailbox_soft_limit",
286+ [{datatype, integer}]}.
0 commit comments