Throw an exception instead of trying to transmit a header frame that exceeds max frame size

[ibolotin]

We ran into production issue with messages that had single huge header that exceeded max frame size. The client just creates and transmits huge header frame to server and as a result server shuts the connection down with frame_too_large error and that breaks all open channels and creates multiple application failures in completely unrelated threads as a result. This issue was very difficult to diagnose, but very easy to reproduce once we understood what was happening.

Specific place in the code that handles it is in AMQCommand.transmit method and it does check max frame size and fragments body already, just doesn't do any checks for content header frame.

Looking at rabbitmq/rabbitmq-server#921 - this might be also considered to be server-side issue (not conforming with what is documented), however it would be quite simple also to implement max frame size check on the client side and just reject messages with headers that exceed max frame size instead of trying to transmit header frame that breaks the connection and all its channels.

[michaelklishin]

There is no provision in the protocol that allows for message metadata framing. Bodies are framed but the rest of metadata is assumed to be small enough in practice to fit into a single frame. Note that you can increase the frame size. It's a protocol limitation we cannot address 11 years in, not without very intrusive changes to every client out there. Which would not be worth it.

[ibolotin]

@michaelklishin I'm not asking to fix protocol - I'm asking to add simple check and throw exception in Java client when headers don't fit into single frame.

Note that we did increase frame size initially, but the bug in the application code was constantly increasing size of header value, so it was only temporary workaround for us. The issue was difficult to analyze because it was not the original message that failed, but the fact that connection was shut down after that and the errors were thrown everywhere but in the original thread.

BTW I would be happy to submit pull request to address this issue

[michaelklishin]

Throwing an exception in unsafe situations is definitely something we can do. A PR would be appreciated.

[acogoluegnes]

Fixed by #363.