Setting max_connections for rabbitmq

[Petri Ruutikainen]

In tcp_listener_sup.erl the setting is hard-coded as {max_connections, infinity}. 

Setting it via rabbitmqctl eval 'ranch:set_max_connections({acceptor,{0,0,0,0,0,0,0,0},8883}, 100000).' does the trick.

But could it be made so that if defined in application configuration e.g. rabbit.rabbitmq_mqtt.max_connections, the listener would accept that value when it starts?

[Michael Klishin]

That's a reasonable feature request. Just to be sure,

can you please explain the intent?

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Petri Ruutikainen]

For example I would like have (well, on any given plugin) TCP connections set to infinity and SSL connections set to defined max_connections.

in other words the config would be like 

a) rabbit.rabbitmq_mqtt.tcp.max_connections

b) rabbit.rabbitmq_mqtt.ssl.max_connections

and if the value is not set, it would default to infinity.

To be able to set these values one might have a way of "throlling" for new connections when the connection count starts to hit the roof.

[Michael Klishin]

Right. Connection limiting is typically done via HAproxy or similar. I assume you want to have it

in the core because Ranch already supports it?

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Petri Ruutikainen]

Exactly!

Forgot to mentions Ranch here but you got it correct.

[Michael Klishin]

You already can put Ranch configuration into `rabbitmq.config` (as a sibling to the `rabbit` app).

So, is there really any need for RabbitMQ to set the value? We can do it, I just think it could be

a matter of documenting how to do it via Ranch.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Petri Ruutikainen]

One thing could be to document it how to do it, that would be then a global max_connections value, right?

But if I would like to set the max_connections per plugin, that might not be possible with the current implementation?

[Michael Klishin]

The problem is, it cannot be set per-plugin per se, only per listener or global, as far as I understand. Ranch is unaware of

specific Erlang applications or RabbitMQ plugins.

It's not an unreasonable feature request but between HAproxy and friends connection limiting per port (which hits your goal)

and global configuration that's already possible via Ranch configuration, it's not a no-brainer.

I will ask Ranch maintainer and the rest of our team to chime in here. Maybe there is a way to set a limit per-plugin, I just can't

think of it :)

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Petri Ruutikainen]

Ah true, I might have had you confused in a way. 

Let's say mqtt starts both tcp and ssl listeners.

The way that would be nice is that I could set the tcp listener and ssl listener max_connections separately.

And since tcp_listen_options is carried out to both listeners, defining the max_connections there would make it shared to both tcp and ssl listeners.

Having it only in ssl_options would carry it to ssl listener.

That was my whole point here (but for some reason I started to moan about the plugin stuff).

It then would be the matter of tcp_listener_sup to check that does a max_connections value exits eg. in the SocketOpts (or ProtoOpts) and use that is exists, otherwise infinity.

Or am I still barking at the wrong tree here?

[Michael Klishin]

Someone on our team has a few ideas about making it work per-listener in the new (3.7.0) config. We will see.

For now you should do connection limiting per port using HAproxy or similar :)