Improve connection limits, introduce per-protocol connection limits

@the-mikedavis

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:

Per-user and per-virtual host apply to all protocols
connection_max covers core protocols (AMQP 1.0, AMQP 0-9-1)
{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)

I did a review of what's left to be done in this area.

What Does not Match the Plan

STOMP and Web-STOMP do not enforce the per-user connection limit
MQTT has no mqtt.connections_max (which is expected, we have barely started on the per-protocol limits)
STOMP: no stomp.connections_max (ditto)
Naming inconsistency: the core and stream use connection_max, stream.connection_max but Web MQTT, Web STOMP use {plugin}.max_connections
Web MQTT, Web STOMP use a separate Ranch counter (see 2, 3), so maybe using separate limits for them would be an acceptable way
Management plugin does not have a *.max_connections equivalent
Ranch knob.

What is Already Covered

Per-virtual host limit is enforced in AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, RabbitMQ Stream Protocol, and the direct Erlang client
Per-user limit is enforced in AMQP 0-9-1, AMQP 1.0, MQTT, RabbitMQ Stream Protocol, amd tje direct Erlang client (so, only STOMP is missing)

Related Limits (for Completeness' Sake)

Max channel limits are fully implemented, there's seemingly nothing to do
default_limits.vhosts.$id.max_queues covers queue counts per virtual host

For naming consistency, we should rename stream.connection_max to stream.max_connections (to match Web STOMP, Web MQTT that have already shipped) and if we want, bump Cuttlefish and adopt this key aliasing feature that was introduced specifically for basckwards-compatible renaming, deprecations.

We can support both {plugin}.max_connections and {plugin}.connection_max, and even alias the core connection_max as max_connections for consistency.

@the-mikedavis

@the-mikedavis would you have some cycles to begin working on the TODO items on the list above?

We can start with a new Cuttlefish release (3.7.0), then Cuttlefish bump in RabbitMQ (with backports to v4.2.x), renaming of stream.connection_max with aliasing, and then the gaps, per-protocol limits.

Merge pull request #16367 from rabbitmq/feature/gh-16347-mqtt-connect…

Introduce Ranch-based `management.*.max_connections` and `prometheus.…

@the-mikedavis

@the-mikedavis let me know if this roughly matches what you had in mind w.r.t. per-protocol limits.

Rename `connection_max` to `max_connections` with a backwards compat …

Rename `channel_max` to `max_channels` with a backwards compat alias r…

Update `rabbitmq.conf.example` to use new limit names and mention bac…

Rename `connection_max` to `max_connections` with a backwards compat …

Rename `channel_max` to `max_channels` with a backwards compat alias #…

Update `rabbitmq.conf.example` to use new limit names and mention bac…

@michaelklishin

This looks great, thank you @michaelklishin & @lukebakken !

(Sorry for the late reply, been busy 😅)

Follow-up to rabbitmq#16341: rename `stream.connection_max` to `strea…

Introduce Ranch-based `management.*.max_connections` and `prometheus.…

Navigation Menu

Repository navigation

Improve connection limits, introduce per-protocol connection limits #16347

Problem Definition

HTTP API

Tanzu RabbitMQ Protocols

Remaining Items as a TODO List

What Does not Match the Plan

What is Already Covered

Related Limits (for Completeness' Sake)

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Improve connection limits, introduce per-protocol connection limits #16347

Description

Problem Definition

HTTP API

Tanzu RabbitMQ Protocols

Remaining Items as a TODO List

Activity

michaelklishin commented on May 8, 2026

What Does not Match the Plan

What is Already Covered

Related Limits (for Completeness' Sake)

michaelklishin commented on May 8, 2026

michaelklishin commented on May 8, 2026

10 remaining items

michaelklishin commented on May 13, 2026

the-mikedavis commented on May 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions