Is there a readTimeout equivalent in the new http client?

Gatling (Open-Source)
1

Since upgrading to Gatling 3, I’ve been getting intermittent failures with io.gatling.http.client.impl.HttpAppHandler$1: Premature close

08:52:13.643 [WARN ] i.g.h.e.GatlingHttpListener - Request ‘My Request’ failed for user 1

io.gatling.http.client.impl.HttpAppHandler$1: Premature close

08:52:13.648 [WARN ] i.g.h.e.r.DefaultStatsProcessor - Request ‘My Request’ failed for user 1: j.i.IOException: Premature close ‘My Request’ in this case is a request that triggers a bunch of server-side works and responds in about 4 minutes. With Gatling 2.3, I would set the various timeouts (pooledConnectionIdle, read, and request) to 10 minutes and things worked well enough. With Gatling 3.0.2, I have set the two remaining timeouts to 10 minutes, but the readTimeout is no longer an option. The new behaviour in appears to be that after 1 minute, the request is sent a second time (my server records a second reuqest while still processing the first). I am about to try upping the maxRetry to get around this particular issue, but that’s not ideal if it means extra processing by the server during the test as it handles the retry requests. Is there an alternative? Paul

2

I ran a test on my side (test server replies after 70s, request timeout configured as 120s) and couldn’t reproduce your issue (request completed successfully with 70s response time).

Premature close happens when the server closes the connection while the request is still ongoing.
Please check the issue in not on your side. If so, please provide a reproducer we can run on our side and investigate.

Stéphane Landelle

GatlingCorp CTO
slandelle@gatling.io

3

Found the issue (and it was on our end)!

Around the same time as the Gatling upgrade we also upgraded Play to 2.6. This now uses Akka as the http server and sets an idle timeout where Play 2.5 Netty did not.

Thanks for the prompt reply.