channel_max overrideable?

[Carl Hörberg]

Looks clients can override the "channel_max" property set in rabbitmq.config, is that by design? We would like to be able to enforce it, to keep buggy clients from taking the server down (by creating tens of thousands of channels).

[Michael Klishin]

On 30 July 2014 at 17:20:36, Carl Hörberg (ca...@84codes.com) wrote:
> > Looks clients can override the "channel_max" property set
> in rabbitmq.config, is that by design?

It is negotiated like the rest of the connection values. We can change
this for one particular setting because you pretty much only override
channel_max to limit client resource use. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Carl Hörberg]

Ok, thanks!

[Michael Klishin]

On 30 July 2014 at 18:46:12, Carl Hörberg (ca...@cloudamqp.com) wrote:
> > Ok, thanks!

We have some tests that suggest that the server value is used:
http://hg.rabbitmq.com/rabbitmq-java-client/file/404fb70c7f57/test/src/com/rabbitmq/client/test/server/ChannelLimitNegotiation.java

How did you conduct your test in which a client can override channel_max? 

[Carl Hörberg]

Connect with node-amqp (https://github.com/postwait/node-amqp): https://www.dropbox.com/s/av0qws3yb3he1xn/Screenshot%202014-07-30%2016.58.09.png

[Michael Klishin]

 On 30 July 2014 at 18:58:33, Carl Hörberg (ca...@cloudamqp.com) wrote:
> > Connect with node-amqp (https://github.com/postwait/node-amqp):
> https://www.dropbox.com/s/av0qws3yb3he1xn/Screenshot%202014-07-30%2016.58.09.png

So simply connecting with a client that sets channel_max to 0 to a Rabbit node
which has channel_max configured is sufficient?

[Carl Hörberg]

Yes 

--

You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/Q6TBGjqEBpQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.

To post to this group, send an email to rabbitm...@googlegroups.com.

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

[Michael Klishin]

On 30 July 2014 at 19:02:46, Carl Hörberg (carl.h...@gmail.com) wrote:
> > Yes

Looks like your observations are correct, we'll fix this before 3.3.5.

[Carl Hörberg]

Splendid! Thanks

[Michael Klishin]

On 31 July 2014 at 14:07:19, Carl Hörberg (ca...@cloudamqp.com) wrote:
> > Splendid! Thanks

I have a fix but unfortunately the client won't be notified with connection.close, at least
that's not the case right now.

The reason is how the AMQP 0-9-1 spec dictates negotiation should fail:
"If the client specifies a channel max that is higher than the value provided by the server, the server MUST close the connection without attempting a negotiated close."

This is quite confusing as it will seem to be an authentication failure on client's end.
We may violate the spec and send a connection.close frame.

[Carl Hörberg]

Most clients(?) connects with channel_max=0, will they be disconnected if channel_max is set on the server? Or will they try to negotiate a lowest common number first? I suspect that some clients might not implement a negotiation of channel_max (node-amqp: https://github.com/postwait/node-amqp/blob/master/lib/connection.js#L451), will they break with this behaviour? 

[Michael Klishin]

 On 1 August 2014 at 12:30:03, Carl Hörberg (ca...@cloudamqp.com) wrote:
> > Most clients(?) connects with channel_max=0, will they be
> disconnected if channel_max is set on the server? Or will they
> try to negotiate a lowest common number first? I suspect that
> some clients might not implement a negotiation of channel_max
> (node-amqp: https://github.com/postwait/node-amqp/blob/master/lib/connection.js#L451),
> will they break with this behaviour?

Clients that do not implement negotiation will get authentication failures. If we choose
to violate the spec, they will get a connection.close they need to be prepared to handle.

I think fixing broken clients such as node.amqp is hard to avoid: even if RabbitMQ does its best to clarify what the error is but the client is not ready to present it in a sensible way,
there will be confusion involved.

At the very least node.amqp needs to stop using channel_max = 0 by default. 65536 is a reasonable
default value and no Bunny user has ever complained about it.

[Carl Hörberg]

Ok, made a PR to node-amqp: https://github.com/postwait/node-amqp/pull/350

[Carl Hörberg]

Even if the negotiation succeeds, will the server monitor that the client respects it? It might say that it will use channels_max upon connecting, but then by a bug or otherwise still create more channels. If it does, will it just not allow the client to open the channel or will it disconnect the client completely?

To unsubscribe from this group and all its topics, send an email to rabbitmq-users+unsubscribe@googlegroups.com.

To post to this group, send an email to rabbitmq-users@googlegroups.com.

[Michael Klishin]

 On 1 August 2014 at 12:51:48, Carl Hörberg (ca...@cloudamqp.com) wrote:
> > Even if the negotiation succeeds, will the server monitor that
> the client respects it? It might say that it will use channels_max
> upon connecting, but then by a bug or otherwise still create more
> channels. If it does, will it just not allow the client to open
> the channel or will it disconnect the client completely?

The client will get a NOT_ALLOWED. Otherwise the limit would make no sense.

[Carl Hörberg]

Ok, great. 

--

You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/Q6TBGjqEBpQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.

To post to this group, send an email to rabbitm...@googlegroups.com.

[Carl Hörberg]

Submitted PR to node-amqp and streadway/amqp (for golang). Checked py-amqp and it does respect channelMax.

Does any other major clients that might not implement channelMax/overflows come to your mind? I assume Ruby Bunny, ruby amqp, the java client, the. net client etc already does it.

[Laing, Michael]

I see that pika (python) also negotiates channel_max and detects overflows.

--
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.

[Michael Klishin]

On 1 August 2014 at 18:04:28, Carl Hörberg (ca...@84codes.com) wrote:
> > Does any other major clients that might not implement channelMax/overflows
> come to your mind? I assume Ruby Bunny, ruby amqp, the java client,
> the. net client etc already does it.

They do. JavaScript, Go, Perl, Haskell clients need verification .

[Carl Hörberg]

Client status report:

Perl - AnyEvent::RabbitMQ: https://rt.cpan.org/Public/Bug/Display.html?id=97716 (other perl libs seems to rely on this lib, librabbitmq-c or the java client)
js - node-amqp: https://github.com/postwait/node-amqp/pull/350
js - node.amqp: https://github.com/squaremo/amqp.node/pull/83
Haskell - amqp: https://github.com/hreinhardt/amqp/pull/35
go - streadway: https://github.com/streadway/amqp/pull/116
python - pika: verified
python - py-amqp: verified
ruby - bunny: verified
ruby - amqp: verified
java: verified
.net: verified
c - librabbitmq-c: verified

[Carl Hörberg]

Maybe the server should suggest 65535 as channel max as default? Or is it already?

On Sunday 3 August 2014 at 12:53, Carl Hörberg wrote:

> Client status report:
>
> Perl - AnyEvent::RabbitMQ: https://rt.cpan.org/Public/Bug/Display.html?id=97716 (other perl libs seems to rely on this lib, librabbitmq-c or the java client)
> js - node-amqp: https://github.com/postwait/node-amqp/pull/350
> js - node.amqp: https://github.com/squaremo/amqp.node/pull/83
> Haskell - amqp: https://github.com/hreinhardt/amqp/pull/35
> go - streadway: https://github.com/streadway/amqp/pull/116
> python - pika: verified
> python - py-amqp: verified
> ruby - bunny: verified
> ruby - amqp: verified
> java: verified
> .net: verified
> c - librabbitmq-c: verified
>
> On Saturday, August 2, 2014 8:13:00 AM UTC+2, Michael Klishin wrote:

> > On 1 August 2014 at 18:04:28, Carl Hörberg (ca...@84codes.com (javascript:)) wrote:
> > > > Does any other major clients that might not implement channelMax/overflows
> > >
> > > come to your mind? I assume Ruby Bunny, ruby amqp, the java client,
> > > the. net client etc already does it.
> >
> >
> > They do. JavaScript, Go, Perl, Haskell clients need verification .
> > --
> > MK
> >
> > Staff Software Engineer, Pivotal/RabbitMQ

> --
> You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/Q6TBGjqEBpQ/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com (mailto:rabbitmq-user...@googlegroups.com).
> To post to this group, send email to rabbitm...@googlegroups.com (mailto:rabbitm...@googlegroups.com).

[Michael Klishin]

On 3 August 2014 at 15:58:11, Carl Hörberg (carl.h...@gmail.com) wrote:
> > Maybe the server should suggest 65535 as channel max as default?
> Or is it already?

It's currently 0:
http://hg.rabbitmq.com/rabbitmq-server/file/dba10965c62e/ebin/rabbit_app.in#l28.

I think changing the server default is a good idea. Not sure we can do this in 3.3.x ,
though.

[Carl Hörberg]

No? Isn't it a less intrusive change than enforcing channel max?


On Sunday 3 August 2014 at 14:01, Michael Klishin wrote:

> On 3 August 2014 at 15:58:11, Carl Hörberg (carl.h...@gmail.com (mailto:carl.h...@gmail.com)) wrote:
> > > Maybe the server should suggest 65535 as channel max as default?
> >
> >
> > Or is it already?
>
>
> It's currently 0:
> http://hg.rabbitmq.com/rabbitmq-server/file/dba10965c62e/ebin/rabbit_app.in#l28.
>
> I think changing the server default is a good idea. Not sure we can do this in 3.3.x ,
> though.
> --
> MK
>
> Staff Software Engineer, Pivotal/RabbitMQ
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/Q6TBGjqEBpQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com (mailto:rabbitmq-user...@googlegroups.com).

> To post to this group, send an email to rabbitm...@googlegroups.com (mailto:rabbitm...@googlegroups.com).

[Michael Klishin]

 On 4 August 2014 at 17:52:13, Carl Hörberg (ca...@84codes.com) wrote:
> > Isn't it a less intrusive change than enforcing channel max?

If you enforce channel_max but both parties use 65K or 0 as the limit,
things should keep working.

If you enforce the limit and then change server default, not necessarily so.