Gatling does not stop

[Bene Csaba]

After executing some requests gatling starts to do this :

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

2018-03-13 15:05:09                                        1270s elapsed

---- Requests ------------------------------------------------------------------

> Global                                                   (OK=685    KO=212   )

I limited the time for one request :

gatling.http.ahc.requestTimeout=30000

which can be seen here

> j.u.c.TimeoutException: Request timeout to *****    65 (30.66%)

URL**** after 30000 ms

> j.n.ConnectException: connection timed out: **** URL ***      3 ( 1.42%)

(***URL*** is a real existing url, which I can not share) 

I dont want to limit the total running time, but this, I would like to stop after 60 sec....

Any ideas ?

[Stéphane LANDELLE]

Which version of Gatling do you use?

Can you please provide a sample that reproduces your problem?

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bene Csaba]

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

    .baseURL(init.getMainUrl())

    .inferHtmlResources(BlackList(), WhiteList())

    .acceptEncodingHeader("gzip,deflate")

    .contentTypeHeader("text/xml;charset=UTF-8")

    .userAgentHeader("Apache-HttpClient/4.1.1 (java 1.5)")

    .disableAutoReferer

  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(

      doIf(session=>testName=="retrieve")(

        asLongAs(session=>init.hasStopped()>0) {

            feed(feeder).exec(DemoRequest.retrieve)

        }

      )

  )

  val retrieveVehicleBipScenario = scenario("retrieveVehicleBipScenario").exec(

      doIf(session=>testName=="retrieve")(

        asLongAs(session=>init.hasStopped()>0) {

            feed(feederBip).exec(DemoRequest.retrieve)

        }

      )

  )

 setUp(

      vehicleScenarioBip.inject(atOnceUsers(50)),

      vehicleScenarioCasa.inject(atOnceUsers(50))

  ).protocols(httpProtocol)

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 ?

[Bene Csaba]

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. 

[Bene Csaba]

This is how it starts :

HTTP request:

GET https://<VALIDURL>/restForward/vehicle/v1/LOADTEST_CAS_0082

headers=

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

Host: <VALIDURL>

Accept: */*

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

HTTP response:

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

16:02:25.032 [DEBUG] o.a.n.h.HttpHandler - Channel Closed: [id: 0x58023df3, L:/172.29.176.111:52486 ! R:<VALIDURL>] with attribute INSTANCE

16:02:25.032 [DEBUG] i.g.c.a.Exit - End user #26

16:02:25.032 [DEBUG] i.g.c.c.Controller - End user #26

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

2018-03-13 16:02:25                                         130s elapsed

---- Requests ------------------------------------------------------------------

[Stéphane LANDELLE]

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.

Stéphane Landelle

GatlingCorp CEO

slan...@gatling.io

[Bene Csaba]

Gatling has no option to limit the wait time, after the last request sent  ?

http.ahc.readTimeout ?

ttp.ahc.webSocketTimeout ?

timeOut.simulation ?