Error with more than 10 connection

Hey guys,

When i try to use Gatling with more than 10 connection i get some errors :

16:58:29.167 [WARN ] c.e.e.g.h.a.GatlingAsyncHandler - Request ‘insertion’ failed
java.util.concurrent.TimeoutException: Idle connection timeout of 60000 ms
at com.ning.http.client.providers.netty.timeout.TimeoutTimerTask.expire( [async-http-client-1.8.3.jar:na]
at [async-http-client-1.8.3.jar:na]
at org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout.expire( [netty-3.8.0.Final.jar:na]
at org.jboss.netty.util.HashedWheelTimer$Worker.notifyExpiredTimeouts( [netty-3.8.0.Final.jar:na]
at org.jboss.netty.util.HashedWheelTimer$ [netty-3.8.0.Final.jar:na]
at [netty-3.8.0.Final.jar:na]
at [na:1.7.0_51]

But, it appears that the request are ok, i can find them in my database.

Do i need to change in my Java cinfig or something ?

Greetings !

Are they all here?

My 2cents: you have a dead lock in your database or something similar.

Anyway, the problem is not in Gatling but in your application. Investigate there.

That stacktrace is a bug as far as I am concerned. Gatling should not print stacktraces for problems on the server side. All that does is confuse the user into thinking there is a Gatling problem when in reality Gatling just successfully found a server limitation.

Of course when you’re debugging Gatling or akka, that’s something else…

… not to mention polluting logs…

That is a good point.
I created an issue:

You’re welcome :slight_smile:

Thanks for the answers !

Ok, now i get it, the warn means that my server got some limitation somewhere, i’m going to digg into this.

But, I still not understand why Gatling says 8/10 of my request failed if i can see them in my database – in my app if there is something in my db it means the request succeed, the code parsed it and stored it. Is gatling should not returns these request with WARN in orange instead of red ?

Gatling says those requests failed because they timed out and didn’t even respond from an HTTP standpoint.

It’s possible that the requests arrive, get processed to the point of writing to the database, but then run into some problem while trying to send the answer. That is pretty much the behaviour you’re describing here.

The million dollar question of course would be ‘why’, but without some deep digging with something like dynatrace or appdynamics, that’s going to be hard to answer.

There’s a pretty good chance that the problem is in your application.
Depending on the technology, simple monitoring tools such as VisualVM or Yourkit will probably suffice.