Per-user connection limit

[johnfoldager]

It would be really great if it was possible to limit the number of connections/channels for a specific user.

[michaelklishin]

You can do this via HTTP API today (poll and force close connections). However, I expected to see this after #500 and they have a lot of similarities.

We won't be providing a channel limit per user but you can limit max number of channels per connection via rabbit.channel_max.

[michaelklishin]

@johnfoldager in your opinion, should this limit be global or scoped per vhost? We see a lot of interest in per-vhost connection limit (already done, #500) but there is no consensus on this one.

[michaelklishin]

We'd like to understand the use cases better before we spend more than a spike worth amount of time on this => clearing milestone.

[wmoran-uatc]

With the current setup, an application with a connection leak can crash RabbitMQ when it runs out of file descriptors. If a per-user connection limit could be enforced, it could be guaranteed that one application with a connection leak won't crash Rabbit (thus causing problems for all applications that use it). This would provide a more stable backend for systems that are developed rapidly enough that bugs occasionally sneak through.

[michaelklishin]

@wmoran-uatc we have introduced per-vhost connection limit in #500. However, we now fail to come up with a compelling use case for this per-user limit and there's no time to fit it into the 3.7.0, too. So it is on the back burner but the benefits of connection limits are clear to our team :)

[wmoran-uatc]

While per-vhost is an excellent feature, it still fails to provide protection in the case where multiple teams are creating software that connects to the same vhost. With per-vhost, a single buggy app could eat up all the connections for a particular vhost, thus negatively impacting other applications that need to use that vhost. With per-user limits, each application could be limited independently of any other.

[michaelklishin]

@wmoran-uatc we will consider this feature for a future release, thank you.

[cwhsu1984]

I would love to see rabbitmq to have this feature, I currently plan to let users connect to rabbitmq through Web STOMP. However, I just want to have only one connection per user to rabbitmq to prevent users from draining the resources(cpu, memory) on the rabbitmq node. Although, I might be able to do this by closing user connection when a user tries to login to our server, still, it would be great if rabbitmq support this feature.

[jesferman]

Is there any planning to include this feature in some RabbitMQ release?

[michaelklishin]

@jesferman not into 3.7.0, then we will see.

[barryz]

What's going on?

[michaelklishin]

There are no updates on this feature. We still see relatively little demand for it, so at the moment it is not in the backlog for 3.8 or any other release. We will update this issue should that change.

[neilneely]

Having just experienced the scenario @wmoran-uatc described above - where a new single buggy app was leaking connections and caused us considerable grief in production - I'd like to reiterate that a per-user connection limit would be a very helpful mitigation strategy when the whole purpose of a given MQ cluster is supporting a single high volume vhost.

[hanej]

I too would like to put my vote in for per-user level limits. We have several groups that will be connecting to the same vhost and we don't want one group to exhaust all resources on the machine. Limiting them to a few connections would be the right way to go.

[michaelklishin]

Locking since a couple of use cases for this have been explained to our team and we don't need any more +1s until we actually get to investigate it.

[michaelklishin]

In #2380, CloudAMQP and Erlang Solutions have contributed an implementation of this.

[michaelklishin]

#2380 has been merged manually and has a good change of getting into a future 3.8.x release after additional evaluation. This feature required internal schema changes so it is hidden behind a feature flag for mixed version cluster compatibility.

[michaelklishin]

We will set the milestone when we decide when/if this should be backported.

[mattfiocca]

I recognize this comment is better suited for the mailing list (started here: https://groups.google.com/u/2/g/rabbitmq-users/c/DY_rqcV7mWU), but is it possible to interact with the user-level connections limits in 3.8 via the http auth backend? Is it better for us to have our own monitor running for these dynamic user connections?