Unbounded Write Queue in Boost.MQTT5

[Th-Wilczek-Resuscitec]

using write_queue_t = std::vector<write_req, queue_allocator_type>;
write_queue_t _write_queue;  // NO MAXIMUM SIZE LIMIT

Every async_publish call adds a write_req to this queue. Each write_req holds:

• A const_buffer to the serialized MQTT PUBLISH packet (payload data)
• A completion handler (captures topic string)

Flow When Broker Is Unreachable

1. async_publish → publish_send_op::send_publish() → async_send() → _write_queue.emplace_back() (line 164 of async_sender.hpp)
2. do_write() calls _svc._stream.async_write()
3. TCP async_write hangs (does not fail immediately when broker is unreachable — socket is in connecting/limbo state)
4. write_reqs accumulate in _write_queue
5. queue grows unbounded → OOM

[biljazovic]

Thanks for the detailed write-up. The analysis of the code path is accurate.

For QoS 1 and QoS 2, the queue is already implicitly bounded by the MQTT5 spec: every such publish must allocate a unique packet identifier, and those only go up to 65535. Once they're exhausted, the publish completes immediately with client::error::pid_overrun.

QoS 0 has no such protocol-imposed bound. We leave control to the application, which can track outstanding publishes via the handler passed to async_publish. That allows the application to implement the policy that best fits its use case (for example, blocking, dropping the oldest message) using whatever metric is appropriate.