Gatling 2.0.1 Running Exception

Gatling (Open-Source)
1

Hi, we were doing a test and unfortunately the server was not in a good shape so most of the requests were KOs. But when simulation finished, gatling showed this error to us. And later when our own log parser tried to read data from file data reader, one group stats was missing.

is this a potential Gatling bug that the simulation log was not complete so data reader could not parse and return all stats properly?

Simulation finished
[INFO] [10/31/2014 16:36:50.807] [GatlingSystem-akka.actor.default
-dispatcher-8] [akka://GatlingSystem/user/$a] Message [io.gatling.core.controller.OneSecondTick$] from Actor[akka://GatlingSystem/user/$a#1315663231] to Actor[akka://GatlingSystem/user/$a#1315663231] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings ‘akka.log-dead-letters’ and ‘akka.log-dead-letters-during-shutdown’.
[ERROR] [10/31/2014 16:36:50.944] [GatlingSystem-akka.actor.default-dispatcher-8] [ActorSystem(GatlingSystem)] exception while executing timer task
java.lang.IllegalStateException: cannot enqueue after timer shutdown
at akka.actor.LightArrayRevolverScheduler.scheduleOnce(Scheduler.scala:277)
at akka.actor.Scheduler$class.scheduleOnce(Scheduler.scala:117)
at akka.actor.LightArrayRevolverScheduler.scheduleOnce(Scheduler.scala:182)
at io.gatling.core.scenario.Scenario.io$gatling$core$scenario$Scenario$$batchSchedule$1(Scenario.scala:70)
at io.gatling.core.scenario.Scenario$$anonfun$io$gatling$core$scenario$Scenario$$batchSchedule$1$2.apply$mcV$sp(Scenario.scala:78)
at akka.actor.Scheduler$$anon$7.run(Scheduler.scala:117)
at akka.actor.LightArrayRevolverScheduler$TaskHolder.run(Scheduler.scala:476)
at akka.actor.LightArrayRevolverScheduler$$anonfun$close$1.apply(Scheduler.scala:282)
at akka.actor.LightArrayRevolverScheduler$$anonfun$close$1.apply(Scheduler.scala:281)
at scala.collection.Iterator$class.foreach(Iterator.scala:727)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
at akka.actor.LightArrayRevolverScheduler.close(Scheduler.scala:280)
at akka.actor.ActorSystemImpl.stopScheduler(ActorSystem.scala:687)
at akka.actor.ActorSystemImpl$$anonfun$liftedTree2$1$1.apply$mcV$sp(ActorSystem.scala:616)
at akka.actor.ActorSystemImpl$$anonfun$liftedTree2$1$1.apply(ActorSystem.scala:616)
at akka.actor.ActorSystemImpl$$anonfun$liftedTree2$1$1.apply(ActorSystem.scala:616)
at akka.actor.ActorSystemImpl$$anon$3.run(ActorSystem.scala:640)
at akka.actor.ActorSystemImpl$TerminationCallbacks$$anonfun$run$1.runNext$1(ActorSystem.scala:807)
at akka.actor.ActorSystemImpl$TerminationCallbacks$$anonfun$run$1.apply$mcV$sp(ActorSystem.scala:810)
at akka.actor.ActorSystemImpl$TerminationCallbacks$$anonfun$run$1.apply(ActorSystem.scala:803)
at akka.actor.ActorSystemImpl$TerminationCallbacks$$anonfun$run$1.apply(ActorSystem.scala:803)
at akka.util.ReentrantGuard.withGuard(LockUtil.scala:15)
at akka.actor.ActorSystemImpl$TerminationCallbacks.run(ActorSystem.scala:803)
at akka.actor.ActorSystemImpl$$anonfun$terminationCallbacks$1.apply(ActorSystem.scala:637)
at akka.actor.ActorSystemImpl$$anonfun$terminationCallbacks$1.apply(ActorSystem.scala:637)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
at akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.processBatch$1(BatchingExecutor.scala:67)
at akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:82)
at akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply(BatchingExecutor.scala:59)
at akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply(BatchingExecutor.scala:59)
at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72)
at akka.dispatch.BatchingExecutor$Batch.run(BatchingExecutor.scala:58)
at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:41)
at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

2

Are you using something like maxDuration?

3

yes. as the following

.maxDuration(Properties.durationMin minutes)

4

Yeah, so that’s a race condition during shut down I haven’t been able to solve for now.
It only happens with maxDuration.

I’ll open an issue so I don’t forget to try again to fix it.

5

I see. it doesnt happen very often but it happens. It will be great if you can fix it.

6

https://github.com/gatling/gatling/issues/2351

Not a top priority though. I don’t get why Akka decides to log those as ERROR while dead letters are INFO…

7

I got the same error with Gatling 2.0.2.

If it’s not a priority to fix, I can understand that.

However, I’m still not sure what this command / function actually does. I’m also not sure if it works in in spite of the error message, because I’m not sure what to look for.

From the name it seemed like I could use this command to shut down the Simulation in case the normal time constraints got missed somehow. Most of my scripts run on a Jenkins server, but I occasionally find scripts that run 2-4 times longer than the durations I’ve entered into the injection profile. I’m not sure what causes this, but it would be nice to have a fallback measure to manage this automatically.

Is this the correct use case for maxDuration?

8

That’s just some internal shutdown events that don’t occur in the proper order. maxDuration just kills the simulation after the given period (if it wasn’t already finished).

This will be fixed in 2.1

9

Wow, that's good news!

Thanks.