Gatling does not stop

After executing some requests gatling starts to do this :

Which version of Gatling do you use?
Can you please provide a sample that reproduces your problem?

I am using the one available in maven , 2.3.1

It is a standard code, which works on localhost :

class DemoTest extends Simulation {
I use this to control the logic
val init=new DemoTestInitializer()


  • main protocol to use : url is get from parameters
    val httpProtocol = http
    .inferHtmlResources(BlackList(), WhiteList())
    .userAgentHeader(“Apache-HttpClient/4.1.1 (java 1.5)”)

val feederCasa = Iterator.continually(Map( “vin” → init.getCasaVin(), “dest”-> “CASA”,
“gcid”->init.getCasaGcid(), “fail”->init.getFailOver() ))

val feederBip = Iterator.continually(Map( “vin” → init.getBipVin(), “dest”-> “BIP”,
“gcid”->init.getBipGcid(), “fail”->init.getFailOver() ))

object DemoRequest {

val vehicleV1 = http(“vehicleV1-${dest}-${fail}”).get("/restForward/vehicle/v1/${vin}").header(“X-rgw-gcid”,"${gcid}")


val retrieveVehicleScenario = scenario(“retrieveVehicleScenario”).exec(
asLongAs(session=>init.hasStopped()>0) {
val retrieveVehicleBipScenario = scenario(“retrieveVehicleBipScenario”).exec(
asLongAs(session=>init.hasStopped()>0) {



I not the part where is sending requests is failing, but after I hang the server (adding delay 60000)

And I have seen this behavior on other errors as well.
I am using my own creation and control mechanism from java, which works fine, when this is not hanged.

The code in “hasStopped” is not called when this behaviour is in place.

Can I at least see what the hell is gatling waiting for ?

It can not be reproduced, it appears on one server, does not on the other.
I need to limit the time waiting in Gatling after the last sent request, that’s what I am asking how to do.
So if let’s say last request in Gatling was sent 180 sec ago, I need Gatling to stop and generate the request,
considering all pending requests timeout.

This is how it starts :

HTTP request:
GET https:///restForward/vehicle/v1/LOADTEST_CAS_0082
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
X-rgw-gcid: d2e86e2d-be4b-4ad8-a8bf-6244a413a936
Cookie: 556fd0526b082be5ae4e742734fb3196=5ddcfe36801faffa9e4c3b804e58ae39; bec442e9e0d74bbc8434823639ded6d1=a038fd0c4f929c569c6e50d6089c4174
Accept: /

This could be a bug. In this case, it’s impossible to investigate and fix without getting our hands on a way to reproduce on our side.

Gatling has no option to limit the wait time, after the last request sent ?
http.ahc.readTimeout ?
ttp.ahc.webSocketTimeout ?

timeOut.simulation ?