Hi ,
It 's not possible to compress data sended by an HTTP post ?
The better way to do this should be to use byteArrayBody ?
Thks,
Hi,
Request compression is supported out of the box (well, it should, I never tested personally, but that’s a AHC/Netty feature that Gatling simply exposes).
Change requestCompressionLevel is gatling.conf. Default value is -1 for disabled. 6 is a typical value (it’s Netty’s default value when enabled).
Cheers,
Stéphane
Thks for your quick reply.
I try to enable requestCompressionLevel in gatling.conf but it doesn’t work. I try to set the header with differents values: Content-Encoding:gzip, Accept-Encoding:gzip …
I also try to use grizzly or apache but doen’t work :
Here the stacktrace with Netty :
16:27:40.062 [WARN ] c.e.e.g.h.a.GatlingAsyncHandler - Request ‘POST request’ failed
java.lang.IllegalStateException: cannot send more responses than requests
at org.jboss.netty.handler.codec.http.HttpContentEncoder.writeRequested(HttpContentEncoder.java:100) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:280) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:121) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.Channels.write(Channels.java:704) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.Channels.write(Channels.java:671) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) ~[netty-3.6.1.Final.jar:na]
at com.ning.http.client.providers.netty.NettyAsyncHttpProvider.writeRequest(NettyAsyncHttpProvider.java:484) ~[async-http-client-1.7.9.jar:na]
at com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:82) ~[async-http-client-1.7.9.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:427) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:418) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.setSuccess(DefaultChannelFuture.java:362) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker$RegisterTask.run(NioWorker.java:156) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:367) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:291) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) ~[netty-3.6.1.Final.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) ~[netty-3.6.1.Final.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [na:1.7.0_09]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [na:1.7.0_09]
at java.lang.Thread.run(Thread.java:722) [na:1.7.0_09]
Regards,
Mathieu
I wonder if this might be related to this issue: https://github.com/netty/netty/issues/441 (the error message is incorrect when the server returns BAD_REQUEST).
Are you sure that your server supports REQUEST compression?
Yes it should be a netty issue.
Our server support request compression. It works well at runtime, when another server post compressed request body.
Regards
Do you use HTTP or HTTPS?
We use HTTP. The body content that we want to compress is xml.
We build the xml from ssp ressources. without compression it works well.
Thks
Do you have a set up, or even better, a platform I could test against?
I’m pretty sure that the problem comes from Gatling not computing properly the Content-Length header and sending the uncompressed value.
Will investigate next week, hopefully.
I realized this is an old issue that's still open in AHC:
https://github.com/AsyncHttpClient/async-http-client/issues/93
I’ve add a recipe to the cook book that explains how to manually compress the request body:
https://github.com/excilys/gatling/wiki/Compressing-Request-Body
Cheers,
Stéphane