Exception in thread "Thread-1" java.io.EOFException

Hi,

I am receiving a new exception when running the tests which stops the test run.

Exception in thread “Thread-1” java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at sbt.React.react(ForkTests.scala:114)
at sbt.ForkTests$$anonfun$mainTestTask$1$Acceptor$2$.run(ForkTests.scala:74)
at java.lang.Thread.run(Thread.java:745)
[info] Simulation(s) execution ended.
[error] Error during tests:

I am using gatling 2.1.3.

Is there any more information, I can provide for you.

Adrian

Mystery: https://github.com/sbt/sbt/issues/653

We would need a reproducer…

This is the test I am running.
https://github.com/BBC/gatling-load-tests/blob/master/src/test/scala/bbc/sport/ThingsToDo.scala

It is a high load, so I do some tuning beforehand.
https://github.com/BBC/gatling-load-tests/blob/master/bin/linux-tuning

I have also seen the test freeze (no errors)

Many Thanks

Adrian

My2cents: the test crashes for whatever unknown reason but sbt swallows what happens and throws this weird EOF.
Can you try running your test with the standard bundle, please?

Hi Stephane

I ran the test through the download bundle on an m3.xlarge. Even though I have a ramp-up for 10 mins the test progress bar hits around 8 or 9% and doesn’t move beyond this ( although requests are still being sent). The test will not finish without sending a termination signal.

Adrian

Could you try generating the reports from the incomplete simulation.log file, after killing? Use the -ro (reports-only) option.

http://gatling.io/docs/2.1.4/general/configuration.html#command-line-options

Also, did you trying monitoring GC during the run? It could be that the heap is full, causing GC to pass all the time.

I just ran a quick test with your simulation (from OSX, you I couldn’t properly raise the fd limit and quickly ran out of fd).
Anyway, after 30 seconds, I has ~600 concurrent active users, and response time was already very bad.

I think you’re quickly way past the limits of your system under test, but you keep on throwing new virtual users at it.
As virtual users take forever to complete the full scenario and exit, they just pile up in memory.
At some point, you end up with a full non-GCable heap, and GC keeps on being triggered but not being able to free anything, cause the JVM to freeze.

).