Any experience with that? Particular things to watch for?
Want a web page where user can click a button to kick off a Simulation, have it run, then return results to user.
Wondering if anyone has tried similar.
Thanks.
Well, I haven’t heard of such a thing before and Gatling is not compatible with the Servlet standard.
So, you’ll have to start gatling as if you would start any other java process from an other process.
The Engine class is a good one to start with.
Cheers
Nicolas
Yes, that’s what I’m doing thanks, hence the other question about capturing outputs and the like.
I know I’m on he bleeding edge here. Wish me luck!
Progress, got Gatling to run just fine from servlet container, emits to stdout, will capture later.
However if I try to kick it off again I get an error.
Caused by: java.lang.IllegalStateException: cannot create children while terminating or terminated
at akka.actor.dungeon.Children$class.makeChild(Children.scala:180)
at akka.actor.dungeon.Children$class.attachChild(Children.scala:41)
at akka.actor.ActorCell.attachChild(ActorCell.scala:306)
at akka.actor.ActorSystemImpl.actorOf(ActorSystem.scala:512)
at io.gatling.core.action.builder.FeedBuilder$.io$gatling$core$action$builder$FeedBuilder$$newInstance$1(FeedBuilder.scala:31)
at io.gatling.core.action.builder.FeedBuilder$$anonfun$apply$1.apply(FeedBuilder.scala:33)
at io.gatling.core.action.builder.FeedBuilder$$anonfun$apply$1.apply(FeedBuilder.scala:33)
at scala.collection.mutable.MapLike$class.getOrElseUpdate(MapLike.scala:189)
at scala.collection.mutable.AbstractMap.getOrElseUpdate(Map.scala:91)
at io.gatling.core.action.builder.FeedBuilder$.apply(FeedBuilder.scala:33)
at io.gatling.core.structure.Feeds$class.feed(Feeds.scala:34)
at io.gatling.core.structure.AbstractStructureBuilder.feed(AbstractStructureBuilder.scala:27)
at TestApp2App.(TestApp2App.scala:165)
Any idea?
You can get that error happening outside of web container simply by having engine do:
Gatling.fromMap(props.build)
Gatling.fromMap(props.build)
i.e. twice.
Thanks.
Dino.
This also leads on to another question I have, and that is how thread safe is Gatling?
i.e. can I run 2 Gatling simulations at the same time. I’m guessing no. Trouble is I want to run all this via web ui so concurrency is pretty much a given.
I know the normal use case is Gatling starts up with VM, does its work, then VM exits.
The very fact that Gatling doesn’t return console info or report name to caller via Engine would also be a problem.
I don’t want to have to rewrite all my stress test stuff with something else, especially throwing away all the lovely graphs.
Thanks.
Any one?
Dino.
Hi Dino,
Sorry for the delay.
We haven’t build Gatling with the idea of running multi instances inside the same JVM, so honestly, I’m not sure it would work (meaning that it could, but I haven’t the cycles to try myself at the time).
Then, are you sure that running Gatling from Jenkins, with the Gatling plugin doesn’t meet your needs? You’d be able to launch Gatling from a web ui and even get the reports.
Cheers,
Stéphane
Unfortunately we need people to run it on demand, have a ui to choose various options, have it running concurrently etc (probably not in stress test mode, just some useful functional tests).
If I could get a fix or work around of the above exception then at least I could run it repeatedly, if only one at a time. They’d just have to get in a queue.
Caused by: java.lang.IllegalStateException: cannot create children while terminating or terminated
at akka.actor.dungeon.Children$class.makeChild(Children.scala:180)
at akka.actor.dungeon.Children$class.attachChild(Children.scala:41)
at akka.actor.ActorCell.attachChild(ActorCell.scala:306)
at akka.actor.ActorSystemImpl.actorOf(ActorSystem.scala:512)
at io.gatling.core.action.builder.FeedBuilder$.io$gatling$core$action$builder$FeedBuilder$$newInstance$1(FeedBuilder.scala:31)
at io.gatling.core.action.builder.FeedBuilder$$anonfun$apply$1.apply(FeedBuilder.scala:33)
at io.gatling.core.action.builder.FeedBuilder$$anonfun$apply$1.apply(FeedBuilder.scala:33)
at scala.collection.mutable.MapLike$class.getOrElseUpdate(MapLike.scala:189)
at scala.collection.mutable.AbstractMap.getOrElseUpdate(Map.scala:91)
at io.gatling.core.action.builder.FeedBuilder$.apply(FeedBuilder.scala:33)
at io.gatling.core.structure.Feeds$class.feed(Feeds.scala:34)
at io.gatling.core.structure.AbstractStructureBuilder.feed(AbstractStructureBuilder.scala:27)
at TestApp2App.(TestApp2App.scala:165)
You can get that error happening outside of web container simply by having engine do:
Gatling.fromMap(props.build)
Gatling.fromMap(props.build)
Sorry, had missed the message with the exception.
The problem is that Gatling’s actor system is a singleton that gets closed after the simulation, and in 2M3a, it never gets a chance to be re-started.
The funny thing is that I changed that in master yesterday. 
So:
- trying to run several Simulations in // won’t work (singleton)
- queueing them should work (haven’t tested this set up) with latest snapshot: http://repository-gatling.forge.cloudbees.com/snapshot/
- You’ll have a small migration effort: we’ve changed the inject API a bit, got rid of the weird imports (bootstrap., assertions.). You can send me a small sample and I can migrate it for you.
Cheers,
Stéphane
Looks like I’ll have to look at something else for my web app. I really do need concurrent safe code for use in my web app. e.g. Dispatch, Spray Client, Newman etc.
Its still good to use as an application for stress testing, but all I really need for my web app is a nice http client that can run concurrently. Didn’t want to have to learn another
HTTP client API.
The Gatling API is really nice, ever thought of splitting off the DSL for request building so you have a standalone http client? One that doesn’t have the below singleton?
You can see for yourself how it currently dies, just do a
Gatling.fromMap(props.build)
Gatling.fromMap(props.build)
And some feeder. Bang!
Dino.
Gatling was built as a stress tool, so it’s not supposed to have to compete for resources.
Maybe we could consider your use case. Someday.
Gatling is built on top of async-http-client, just like Dispatch is now.