My company is working refactoring our Groovy framework that wraps Gatling to be fully Scala. The most valuable feature of the framework is that it has the capability of running Gatling more than once, start to finish. Unfortunately, we’re having issues now that we’re running Gatling from Scala, as opposed to in a separate process. We’re at this point right now:
Configure framework.
Pass configuration to Gatling
Gatling runs completely and successfully once.
Framework attempts to run again.
??? Nothing happens.
We’re just wondering if there’s something inside of Gatling that would prevent this functionality, perhaps state that we need to manually reset?
I’ve gotten to the point where I’ve been hacking away at Gatling 2 itself. From what I can tell, it’s how interactions with Akka have been implemented, once Akka is shutdown, you can’t restart it and no errors are given. The further I go, the most of a rabbit hole it seems to be:
Had to overwrite io.gatling.app.Gatling’s start method to call my own Runner.
Had to write my own Runner class, which will only start Akka if it isn’t already running the Gatling System, it also calls a custom Controller.
The point I’m at now is that rewriting the Controller so it can create a new Controller for each time I run Gatling, as the Controller is implemented as a singleton and terminates its DataWriter after completion.
It seems surprising to me that all of this is necessary… I’m basically being forced into rewriting Gatling core. Is this something that could helped on your end, Stephané, and if I continue to work on this, would you be open to making this part of Gatling 2?
Sorry for the delay. I’m currently implementing what you need, basically having all singletons/state holders be restartable once simulation is finished.
Just pushed on master. Either build yourself or wait for the build on Cloudbees to complete (https://gatling.ci.cloudbees.com) and fetch the snapshot on Sonatype.
This is good progress - thanks. Although it looks like this isn’t complete. Is there something that I need to do on my end to restart, it looks like the code is intended to do it without any intervention by developers. Updating to the latest snapshot and rolling back our manual changes, we’re still encountering the halt which prevents the second execution.
At some point yes. But I realize that you won’t be able to run multiple Gatling instances ate the same time in the same JVM, you’ll have to queue them.
My issue is very much following a queue system, but the two commits I saw (https://github.com/excilys/gatling/issues/1532 and 1533) do not complete this request (sorry if this is redundant - just aiming for clarity).