Post request ends the scenario

I’m new to gatling and i’m very impressed with it’s capabilities.
in my scenario i’m sending a http post request with parameters to our mvc 3 service (IIS or visual studio development server),
the server returns json as a result.
that specific request always terminates the scenario (no error visible error), given:

.exec (some request1)
.exec (post to mvc 3 service)
.exec (some request2)
.exec (some request3)

.exec (some request4)

requests 2,3 and 4 are never sent (can’t be seen in the output and results report)

when changing the post request to a non existing address, all requests are sent.

i’m sorry, but due to security restrictions i can’t post actual code.

did anyone encountered this problem?
are there any additional logs which could help me?

Thanks in advance,

Hi Erik,

Might be difficult without the actual Simulation, but… would you happen by any chance to use Gatling 1.3.1? There was a regression on post params that forced us to release 1.3.2 shortly after.
If so, please upgrade to 1.3.2.

You can also change the log level to DEBUG in logback.xml in order to print the HTTP requests and responses.



2012/10/4 erik ashepa <>

Thanks for the quick reply!

i’m attaching the console output (debug level) and the scenario.

looking at the logs the request are not sent…


output_debug.txt (13.9 KB)

scenario.txt (955 Bytes)

sorry… forgot to mention that i am using the latest version 1.3.2.

There are those messages in the logs :

15:40:40.131 [INFO ] c.e.e.g.h.a.HttpRequestAction - Bypassing cached Request 'open_position_request2': Scenario 'Successful Login Scenario', UserId #1
15:40:40.132 [INFO ] c.e.e.g.h.a.HttpRequestAction - Bypassing cached Request 'open_position_request3': Scenario 'Successful Login Scenario', UserId #1

Stéphane, does it make sense to cache POST queries ?

adding .disableCaching to the httpConf solved the problem!

note to development:
this should probably be the default behavior…

thank you Nicholas!


Well, from the RFC perspective, Caching has nothing to do with the HTTP method, but with Expires and Cache-Control headers.
What happens here is actually a bug with the caching algorithm.
Will fix.

2012/10/4 erik ashepa <>

Here is the issue:

It has been fixed, so a snapshot should be available in the CI repository in about 20 minutes.

@Erik. Thanks for reporting. And no, this should be disabled by default as it’s the expected browser behavior (when implemented correctly 329.png).



2012/10/4 Stéphane Landelle <>