Dandling Connection after upgrade to 2.2.0

Gatling (Open-Source)
1

Hi,

After we upgraded gatling to 2.2.0 / 2.2.2 from 2.1.6 , we are facing a dandling connections issue.
After the test duration is complete , the test does not exit , we can still see some active users in the logs.

This issue seems have been observed earlier , http://gatling.io/docs/2.2.2/project/faq.html
But setting this config is not helping.

Any ideas ?

Regards
Prashant

2

Please provide app and simulation samples so we can reproduce.

3

Hi Stephane ,
Below is my Simulation class file , Let me know if any further info needed,

import io.gatling.core.session.SessionAttribute
import io.gatling.core.structure.PopulationBuilder
import io.gatling.http.Predef._
import io.gatling.core.Predef._
import scala.collection.mutable.ListBuffer
import scala.concurrent.duration._

class paLoadScenario extends Simulation
{

var allTypical = “API_pa_1:90,API_pa_2:10”
var BASE_URL = System.getProperty(“url”, “zzzzzzz.com”)
var nDuration : Double = System.getProperty(“steadyDuration”, “1” ).toDouble
var flowSelection=System.getProperty(“flowSelection”, allTypical)
var nDurationRamp : Double = System.getProperty(“rampDuration”, “1” ).toDouble

val execMap:scala.collection.mutable.Map[String, Double]= scala.collection.mutable.Map(
“API_pa_1” → 0,
“API_pa_2” → 0
)

util.initialize(allTypical,flowSelection,execMap);

val pa_data = csv(“data.csv”).random

val httpProtocol = http
.baseURL(“https://”+BASE_URL)
.acceptHeader(“text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”)
.acceptEncodingHeader(“gzip, deflate”)
.acceptLanguageHeader(“en-US,en;q=0.5”)
.connectionHeader(“keep-alive”)
.doNotTrackHeader(“1”)
.userAgentHeader(“Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0”)
.proxy(Proxy(“proxy.net”, 80))

val logger = org.slf4j.LoggerFactory.getLogger(“websPerfLogger”)

val Scenario1=scenario(“Scenario1”)
.feed(pa_data)
.exec(Object1.Transaction1)

val Scenario2=scenario(“Scenario2”)
.feed(pa_data)
.exec(Object2.Transaction2)

val lst: ListBuffer[PopulationBuilder] = ListBuffer()
if(execMap(“API_pa_1”) > 0){
lst+= Scenario1.inject(rampUsersPerSec(0.1) to execMap(“API_pa_1”) during(nDurationRamp minutes),constantUsersPerSec(execMap(“API_pa_1”)) during(nDuration minutes))
}
if(execMap(“API_pa_2”) > 0){
lst+= Scenario2.inject(rampUsersPerSec(0.1) to execMap(“API_pa_2”) during(nDurationRamp minutes),constantUsersPerSec(execMap(“API_pa_2”)) during(nDuration minutes))
}

setUp(lst:_*).protocols(httpProtocol)
.assertions(
forAll.failedRequests.percent.lessThan(20),
forAll.responseTime.percentile3.lessThan(1500)
)
}

4

I would need a sample app under test that exhibits the issue. A simulation doesn’t help.

5

When you say sample app, what are you refering to exactly ?
You want me to send you a test run log which exhibits this issue ?

6

It’s pretty clear what a sample is:

  • either a public facing website, or demo web application that we can use
  • a corresponding full working simulation (not a part of part that doesn’t even compile) that we can use to hit your sample and that then exhibits your problem
7

Hi Stephane,
I would not able to do that owning to sensitive information.
Do you have any tips for me on how i can reproduce this issue.

Note that any version after 2.1.6 is causing this issue. 2.1.6 works fine but 2.1.7 onwards , we face this issue for all the release versions.

8

I had a looking at the commit log between those 2 versions, but couldn’t find any obvious possible culprit.
Could be Gatling, AsyncHttpClient or Netty.

If you can’t grant access, and can’t build a similar and more simple application that you can share, I’m afraid you’ll have to investigate yourself.
You can try building Gatling for each of those commit to try to narrow the culprit.

Otherwise, you can contract with us so we can investigate in your environnement without you having to share publicly.

Regards,