Allow for messages up to the modern RabbitMQ hard upper limit (of 512 MiB)

[davidda]

Proposed Changes

This fixes the bug of not being able to receive messages larger than 128 MiB.

There was a constant InternalConstants.DefaultRabbitMqMaxInboundMessageBodySize which was set to 128 MiB.

However, the only usage of this constant is actually as an upper limit not a default: Math.Min(maxInboundMessageBodySize, InternalConstants.DefaultRabbitMqMaxInboundMessageBodySize)

I renamed the constant to MaximumRabbitMqMaxInboundMessageBodySize to reflect its actual meaning and changed its value to 512 MiB, which is the correct maximum value for max_message_size according to the documentation.

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask on the
mailing list. We're here to help! This is simply a reminder of what we are
going to look for before merging your code.

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

[michaelklishin]

I do not see how this is a bug. The use of such large messages has always been recommended against. Put them into a blob store and pass the ID around.

The maximum message size will likely be decreased again (it used to be 2 GiB or something like that) in future versions, so this constant will likely have to change.

@davidda before the RabbitMQ core team can accept this contribution, we need you to sign Broadcom's contributor CLA. It's done online using Box Sign and the CLA document is just over one page long.

[lukebakken]

Nobody should be sending or receiving 128MiB messages, much less 512MiB. I'm fine with renaming the constant, but I do not want to increase from 128MiB, no matter what RabbitMQ allows.

[davidda]

@lukebakken I'm a bit confused by your response. This is not an opinionated library but a client to RabbitMQ Server, isn't it? Arbitrarily limiting something the server can do is not a good idea, especially as this has worked in a previous version and is now a breaking change for customers.

[lukebakken]

now a breaking change for customers

Which customers? Which of these customers have actually paid or contributed code to support this project, or the RabbitMQ ecosystem in general? If one of them can speak up as to how they need to be able to receive large messages using this library, I'll probably listen.

I have personally had many RabbitMQ support cases whose root cause was, guess what, extremely large messages being published to RabbitMQ.

As @michaelklishin said, future versions of RabbitMQ will most likely reduce the maximum message size below even 128MiB. Personally I hope it is set to 16MiB.

[michaelklishin]

@davidda it's a perfectly reasonable decision for client library maintainers to introduce some practical limits to how the library should be used.

RabbitMQ Core Team recommends against using messages that are hundreds of MiBs or even a few GiBs in size. This has been the case for many years. RabbitMQ storage subsystems can handle such messages but we do not really target such cases, and if you are not careful, you can shoot yourself in the foot with such large messages. We have seen that happen many times.

And yes, if you are not a paying user and not a contributor, your influence on the maintainer decision making will be very limited. If you don't like it, maintain your own fork of this client library.

[davidda]

If you don't like it, maintain your own fork of this client library.

That's exactly what we're (forced to) doing now, until we can get rid of the large messages (which personally we never had an issue with).