[Gatling 3.0.-RC2] Premature close

[Max Calderoni]

Started getting warnings and errors of the sort below saying "Premature close". 

Wonder if anyone had any ideas. Would that be because of HTTP2? and if so, how to go about avoiding those errors?

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

23:39:41.324 [WARN ] - Request 'getUser' failed for user 328 io.gatling.http.client.impl.HttpAppHandler$1: Premature close

23:39:41.324 [ERROR] - Request 'getUser' failed for user 294: j.i.IOException: Premature close

23:39:41.324 [ERROR] - Request 'getUser' failed for user 328: j.i.IOException: Premature close

23:39:41.324 [WARN ] - Request 'getUser' failed for user 320 io.gatling.http.client.impl.HttpAppHandler$1: Premature close

23:39:41.324 [ERROR] - Request 'getUser' failed for user 320: j.i.IOException: Premature close

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

[Stéphane LANDELLE]

Please upgrade to RC4 and provide a way for us to reproduce on our side if issue still happens.

Stéphane Landelle

GatlingCorp CTO

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

[Max Calderoni]

Yes, it still happens with RC4.

Sorry, but after inquiring in my company, i am not sure how i can possibly give you this code to reproduce the issue. This is behind the firewall, and there are login details.

Any hints on your side that you can give me to attempt troubleshooting or isolating in more detail the issue?

[Stéphane LANDELLE]

In Gatling, we have a retry mechanism. This mechanism is intended to deal with situations where Gatling tries to write a request on a socket while at the other end of the wire (network is not instant, so both sides are not aware of what the other is doing), the server closes the socket. The typical use case is keep-alive timeout.

In Gatling 2, this mechanism was not very sound and could kick in while the client has already partially received the response, hence masking some server issues.

In Gatling 3 (that has a new HTTP client), we only trigger retry when we haven't received a partial response. You get a "Premature close":

• either when we've received a partial response, then the connection was closed
• or we've reach the maximum number of retries (2 by default)

I've ran some tests again and wasn't able to find an issue in our implementation.

So I suggest you use Wireshark to get some TCP dumps and check if your server indeed sends partial responses and then closes the socket.

Stéphane Landelle

GatlingCorp CTO

slan...@gatling.io

[Max Calderoni]

Thanks, i think i may have found what the problem is, at least part of it, please confirm if it makes sense...

Code is something like:

  setUp(scn

    .inject(constantUsersPerSec(20).during(30 seconds))

    .throttle(

      jumpToRps(15),

      holdFor(1 minute)

    )

  )

If the duration passed into holdFor() is not long enough for all requests to be processed with a response, a number "premature close" errors are issued.

The documentation (https://gatling.io/docs/3.0/general/simulation_setup/#simulation-setup-throttling) says that "If your injection lasts longer than the throttle, the simulation will stop at the end of the throttle". Which it does, so, the fix was to simply make the hold longer.

Same happens with this kind of code:

  private lazy val scn = scenario("MyScenario")

    .feed(userFeeder)

    .group("Login")(myHttp)

    .exec(forever {

      exec(getUserInfo)

    })

  setUp(scn

    .inject(constantUsersPerSec(100).during(30 seconds))

    .throttle(

      reachRps(60) in (10 seconds),

      holdFor(3 minutes)

    )

  )

In that case it always issues "premature close", because of the forever(), which will be cut off by the throttle duration.