MQTT pingres timeouts under high load — verify on current build (RedHat)

[kriszyp]

Investigative. a customer reported a noticeable increase in MQTT pingres 30s timeouts after a 4.5.11 → 4.5.32 upgrade, causing disconnect/reconnect cycles. Correlated with high load. Expectation is that pingres should remain reliable as long as the server is running.

Verify first

• Confirm whether this pattern still occurs on a current build (5.x). Substantial MQTT/server work has landed since 4.5.32.
• If still reproducible, capture: is the pingres sent later than the 30s timeout, or not sent at all?

To investigate (if reproducible)

• The MQTT keepalive path: how is the response queued, and what could delay it past the 30s window?
• The compounding cost: each timeout triggers a disconnect + reconnect, which adds load — investigate whether the reconnect storm makes the underlying overload worse.
• Whether the MQTT server's pingres handling shares an event-loop or queue with general-purpose work that could starve it under load.

Acceptance criteria (once verified)

• pingres round-trips within the keepalive window under load, or there's a documented backpressure path.
• Disconnect-reconnect storms under load are bounded (not exponentially compounding).

Related

• Internal Slack: thread

---

Tracked in Jira: CORE-2954 (a customer customer escalation)
Status: Not Ready — needs verification on a current build before scoping engineering work.

🤖 Filed by Claude on behalf of Kris.