Header size exception when frame max is negotiated to 0

[lau-sch]

We started facing errors when trying to publish messages after our upgrade to latest client library:

java.lang.IllegalArgumentException: Content headers exceeded max frame size: 47 > 0
	at com.rabbitmq.client.impl.AMQCommand.transmit(AMQCommand.java:115)
	at com.rabbitmq.client.impl.AMQChannel.quiescingTransmit(AMQChannel.java:447)
	at com.rabbitmq.client.impl.AMQChannel.transmit(AMQChannel.java:423)
	at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:704)
	at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:679)
	at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:669)
	at com.rabbitmq.client.impl.recovery.AutorecoveringChannel.basicPublish(AutorecoveringChannel.java:192)
	at com.company.RabbitAppender.append(...)
	at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:82)
	at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
	at net.logstash.logback.appender.DelegatingAsyncDisruptorAppender$DelegatingEventHandler.onEvent(DelegatingAsyncDisruptorAppender.java:54)
	at net.logstash.logback.appender.DelegatingAsyncDisruptorAppender$DelegatingEventHandler.onEvent(DelegatingAsyncDisruptorAppender.java:50)
	at net.logstash.logback.appender.AsyncDisruptorAppender$EventClearingEventHandler.onEvent(AsyncDisruptorAppender.java:330)
	at net.logstash.logback.appender.AsyncDisruptorAppender$EventClearingEventHandler.onEvent(AsyncDisruptorAppender.java:318)
	at net.logstash.logback.encoder.com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:168)
	at net.logstash.logback.encoder.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

This is used to send Logstash/SLF4J log statements to Rabbit, we have control over the ConnectionFactory and we don't set frame max, leaving it as 0 (no limit). These errors appeared when upgrading the client lib from 5.0.0 to 5.4.1.

Apparently it was caused by the fix of this issue, since on this line it checks the frameMax for zero, but 3 lines below it still uses original frameMax to check large headers, causing the exception above.

RabbitMQ 3.7.4
Erlang 20.2.3
Java 1.8.0_181
RabbitMQ client 5.4.1

[michaelklishin]

Since you understand the root cause, why not submit a PR?

I don't know if frame_max of 0 is something we recommend but I'll assume you mean you don't have control over ConnectionFactory settings.

[michaelklishin]

No worries, I will take a look since there's enough information available to put together a test case.

[lau-sch]

@michaelklishin Sorry, I followed the site instructions to run the client tests but I couldn't make the brokers run. I'd submit a PR if I could add and run at least one test for it, and since I couldn't I opted for just reporting it.

[michaelklishin]

For this issue to be reproduced both server and client must be configured to use frame_max value of 0 (which is pretty rare with modern versions).

[michaelklishin]

@lau-sch any chance you can build the client from master and give it a try? It can be done with make deps && make dist, the latter is basically ./mvnw install that skips running tests.

[michaelklishin]

Oh, and the build system depends on a code generator that will require Python and Erlang 20.3+.

[lau-sch]

@michaelklishin Built from latest master, worked great. I haven't seen frame_max configuration suggestions before, but given you comment and the purpose of the parameter I'll be setting it to something adequate given our scenario. Thanks Michael!