Parameter http.requestTimeoutInMs not taken in account

Hi,

I’m doing some tests on a very long request (more than 60 sec.). I tried to configurate the time out of the request in the gatling.conf file.

gatling {
http {


#maximumConnectionsTotal = -1

#maxRetry = 5
#requestCompressionLevel = -1
requestTimeoutInMs = 800000 # Timeout of the requests (ms)

Unfortunately the parameter is not used. The strange fact is that the log indicates the parameter (800000 ms in my case) but it stops after 60s.

13:44:38.017 [WARN ] c.e.e.g.h.a.GatlingAsyncHandler - Request ‘allCECHA’ failed
java.util.concurrent.TimeoutException: No response received after 800000
at com.ning.http.client.providers.netty.NettyAsyncHttpProvider$ReaperFuture.run(NettyAsyncHttpProvider.java:1881) [async-http-client-1.7.12.ja
r:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [na:1.6.0_22]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [na:1.6.0_22]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [na:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [na:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [na:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [na:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_22]
13:44:38.031 [WARN ] c.e.e.g.h.a.GatlingAsyncHandlerActor - Request ‘allCECHA’ failed : No response received after 800000

Hi Gaetan,

Could try to tune the connectionTimeout parameter also ? https://github.com/excilys/gatling/blob/master/gatling-bundle/src/main/assembly/assembly-structure/conf/gatling.conf#L46

cheers
Nicolas

Hi,

@Nico: IMHO, what you suggest would result in a ConnectException

@Gaetan: I suspect idleConnectionTimeout