I’d like to cleanly stop a running test. A simple Ctrl-C won’t work because it can leave my system under test in an inconsistent state. Since every simulation is different, it would be helpful if the DSL supports an exitHereIfStopped function which checks if a SIGINT or SIGHUP is received, so that the simulation author can choose where to exit sanely.
If there’s already a way to do this, please let me know.
What do you mean by “it can leave my system under test in an inconsistent state”?
My simulation performs multi-request interactions on a stateful system. If a user has issued 3 out of 5 requests in a request sequence and I hit Ctrl-C in the simulation, I need to manually clean up the user’s state, or the next simulation run will fail when the user issues request 1 instead of request 4.
Having a controllable exit point avoids the need for tear down code or manual operations, at least in my case.
Honestly: too much hassle, very specific (there’s as many ways to restore state as there’s systems under test) and IMHO not the job of the stress tool.
Can’t you have automated rollback scripts that wrap Gatling launch one?
Umm, I’m not sure we’re talking about the same thing. I’m not suggesting that Gatling should in any way try to clean up the system under test. I’m suggesting the addition of a method like .exitHereIfTerminated which registers a shutdown hook in Gatling, e.g. one that sets a flag, and also exits the simulation if the shutdown hook has been triggered, e.g. if the flag has been set. That allows a simulation author to have more control over where the simulation is terminated, instead of aborting instantly, without modifying default behaviour (I presume to terminate instantly) if exitHereIfTerminated isn’t used.
In my case, that happens to eliminate the need for rollback scripts and the like, but having sane shutdown functionality can’t hurt IMO.
I can’t start to see a way to implement this, sorry.
BTW: the shutdown is sane from a technical point of view. For example, the Http Client is properly closed and the connections released.
My apologies for adding to such an old post, but I seem to be in the exact same situation as the original author of this thread, and it seemed unnecessary to create a new post.
I may have missed it, but as far as I can see, functionality that covers this issue has not been implemented since this, and I still think having it would be both useful and convenient.
I too run multiple requests against a stateful system, and force-quitting the simulation leaves the system testdata in an inconsistent state, because however many currently active scenarios are running will be aborted midway, and this is just one specific example of a use-case where such an option could save many headaches.
I think what both me and Emerson would like to see is a graceful stop option to somehow pass into Gatling, which essentially just causes it to stop injecting more users into the simulation, but otherwise proceeds normally by running any currently active scenarios to its conclusion, and finish by generating the report as it would at an ordinary test-conclusion.
You’d need to be able to interact with a running test, which is currently not possible.
However, this would be possible with our upcoming product.