Trying to understand why we are getting this error HTTP header is larger than 8192 bytes when the request header does not appear to be

sam

unread,

Apr 19, 2016, 1:23:44 PM4/19/16

to Gatling User Group

Hi there

I am running a load test where I am getting this response - org.jboss.netty.handler.codec.frame.TooLongFrameException: HTTP header is larger than 8192 bytes. From the logs (pasted below), we see that there is a Deadlock ( at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.10.1.Final.jar:na])

What would this indicate? There are definitely some performance issues on the product side of things, but trying to figure out what is going on here. Also, is there a limit on the response header size?

HTTP request:

GET https://removedurl

headers=

Accept: */*

Connection: keep-alive

Content-Type: application/json; charset=utf-8

Authorization: removed

=========================

HTTP response:

status=

200 OK

headers=

X-Powered-By: [Express]

Access-Control-Allow-Headers: [X-Requested-With, Authorization, If-Match, Content-Type]

Access-Control-Expose-Headers: [Location, Etag]

Access-Control-Allow-Credentials: [true]

Content-Type: [application/json; charset=utf-8]

Content-Length: [462]

Date: [Tue, 19 Apr 2016 16:02:13 GMT]

Connection: [keep-alive]

body=

["removed json"]

<<<<<<<<<<<<<<<<<<<<<<<<<

13:02:13.818 [INFO ] i.g.c.a.Pause - Pausing for 1000ms (real=908ms)

13:02:13.828 [DEBUG] c.n.h.c.p.n.h.Processor - Unexpected I/O exception on channel [id: 0x9b6e702e, /removed => removeurl]

org.jboss.netty.handler.codec.frame.TooLongFrameException: HTTP header is larger than 8192 bytes.

at org.jboss.netty.handler.codec.http.HttpMessageDecoder.readHeader(HttpMessageDecoder.java:624) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.http.HttpMessageDecoder.readHeaders(HttpMessageDecoder.java:531) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.http.HttpMessageDecoder.decode(HttpMessageDecoder.java:195) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.http.HttpClientCodec$Decoder.decode(HttpClientCodec.java:143) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.http.HttpClientCodec$Decoder.decode(HttpClientCodec.java:127) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.http.HttpClientCodec.handleUpstream(HttpClientCodec.java:92) ~[netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.1.Final.jar:na]

at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.10.1.Final.jar:na]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_60]

Stéphane LANDELLE

unread,

Apr 26, 2016, 5:15:03 PM4/26/16

to gat...@googlegroups.com

Those are securities that are introduced by Netty, but don't really make sense in the context of Gatling.

We'll remove them in a future release.

You can change the setting in gatling.conf.

Stéphane Landelle

GatlingCorp CEO

slan...@gatling.io

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

sam

unread,

May 9, 2016, 6:23:15 AM5/9/16

to Gatling User Group

Hi Stephane

Thanks for the answer. I am a little unclear on which setting to change in gatling.conf here. Could you guide me? Appreciate all that you do. Gatling rocks

Chandra Shaker Avvaru

unread,

Feb 7, 2017, 9:59:23 AM2/7/17

to Gatling User Group

Hi Sam,

In Gatling.conf find httpClientCodecMaxHeaderSize under ahc, update the value. This should fix the problem.

httpClientCodecMaxHeaderSize = 16384 # Maximum size, in bytes, of each request's headers

Regards,

Chandra

David Weston

unread,

Mar 24, 2019, 5:54:29 PM3/24/19

to Gatling User Group

I see that the config has now been removed, but this execution is still thrown for headers over the default size. I cannot see how to override this config. Please advise what this has been replaced with. Thanks