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
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.
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
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
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
Thanks foe confirming.
So are you saying there is no config to work around this issue at present?
Do I need to revert to Gatling 2.3.1 to workaround this for the time being?
Thanks