This is an umbrella issue for a number of closely related discussions on the limits RabbitMQ supports or should support with @the-mikedavis @ansd @acogoluegnes.

Problem Definition

The VMware, Inc. part of the core team proposes reviewing our limits to eventually (likely before 4.4.0) converge on the following limits design/structure/separation:

1. Per-user and per-virtual host apply to all protocols
2. connection_max covers core protocols (AMQP 1.0, AMQP 0-9-1)
3. {plugin}.connection_max covers each plugin protocol, including their Protocol-over-WebSockets variants, so mqtt.connections_max will cover both MQTT and MQTT-over-WebSockets

Note that most of this design is already in place but given the number of limits and protocols RabbitMQ supports, we need to review that nothing is missing, in particular for the per-user and per-virtual host limits.

HTTP API

If we put the WebSockets-based protocols aside, the HTTP API is not really covered by the above limits and given the request-oriented nature of HTTP (even with persistent connections, even with HTTP/2, HTTP/3), the protective measure here is a Ranch-level connection limit introduced in #7753, #7593.

Tanzu RabbitMQ Protocols

connections_max should cover AMQP 1.0-over-Websockets since its a WebSocket variant of the core protocols.

Remaining Items as a TODO List

• Rename stream.connection_max to stream.max_connections (MK)
• Implement mqtt.max_connections (Add mqtt.max_connections per-node connection limit #16367)
• Implement stomp.max_connections (Add stomp.max_connections per-node connection limit #16368)
• Ship Cuttlefish 3.7.0
• Bump Cuttlefish in RabbitMQ to 3.7.0 (Bump Cuttlefish to 3.7.0 #16389)
• Alias connection_max in the core broker as max_connections (rabbitmq.conf: rename connection_max, channel_max in a backwards-compatible way (with aliases) #16414)
• Investigate an optimal solution for the HTTP API (Introduce Ranch-based management.*.max_connections and prometheus.*.max_connections limits #16407)