Gatling RC2: session key reference logged as error during test run

I am using a session key to save a value created by one Object (a Post request) so it can be consumed by another Object (a Delete request).

In Object #1, the http response contains a single GUID that I can extract and save by using a regex convention.
ex.
val x = exec(
http(“my post request”)
.post(“path/to/resource”)
.headers( headers_0)
.body( StringBody( “”"{ “myAwesomePost”: “MyPostValues”""" )).asJSON

.check(status.is(200),
regex(""“ids”:"([^"]*)""").saveAs(“postId”))
)

.pause(3)

If you increase the log level, it should print out the session between requests. Is your first request saving “postId” properly? Can we see the code that exec()s both of these?

Thanks for your response.
I would love to see more output in the console when my Gatling tests run. I originally tried doing a println to show the saved key, but that never showed up in the console output.

There is something slightly different about my setup that is probably worth noting- I am invoking Gatling from a Gradle build script as a child Java process instead of running it as a standalone app.

To accomplish this, I had to modify the standard Gatling directory structure. I found arguments that seemed to allow this that can be passed to io.gatling.app.Gatling main, but have not yet been able to verify that the running app can actually access these custom locations.

Then, when I was working with setting these up, I could not find anything that seemed to apply to customizing location of the Gatling conf directory, so I’m not sure how to do this with my setup. What would you recommend?

I’ve included a copy of the task code (from gradle) that currently runs my tests>

task gatlingPerformance(type: JavaExec, dependsOn: gatlingSmoke) {

description = ‘Runs a single gatling test from gradle command line’
classpath = sourceSets.test.runtimeClasspath
main = “io.gatling.app.Gatling”
args = Eval.me("[’-s’, ‘simulations.MyTest’," +

// set up Gatling tree so the jar can find things

“’-bf’, ‘src/test/scala/request-bodies’,” +
“’-df’, ‘src/test/scala/data’,” +
“’-sf’, ‘src/test/scala/simulations’,” +
“’-rf’, ‘${buildDir}/reports/gatling’]”
)
}

I’ve also included the code that execs Object #1 and Object #2
// scenario
val myTest = scenario(“Run all operations”)
.exec( Object1.createPost )
.exec( someOtherObject.getStuff )
.exec( anotherObject.getStuff )
.exec(Object2.deletePost )

setUp(
feed.inject(atOnceUsers(1))

).protocols(httpProtocol)

I don’t know anything about Gradle, unfortunately - I may be able to help you if you could run your scripts with the bundle. One thing that makes your environment easy to replicate (and I find helps me to debug) is to download a fresh bundle and build from BasicSimulation.scala until you can reproduce your problem. This will give you an example that’s almost as minimal as possible, too. If you can do that, you can change your logback settings and get more info. Otherwise you’ll have to hope someone familiar with Gradle comes along.

Yes, running it this way (from command line) seems to take away a few options for customizing the run. I appreciate you taking the time to respond, and will try to run it as a standalone to see if I can get more console messages.

I also have an update on the test execution. I tried using Object1 (Post request) in a different simulation and scenario. This time, it sets a session key but does not try to pull it out later. However it uses the same type of regex expression.

When I run this new simulation script, I get an error that directly references my regex, so to me this makes me suspect that in the other script, my session key is probably not being captured.

The regex I’m using is this>
regex("""“ids”:"([^"]*)""").saveAs(“postId”))

The response I want to parse looks like looks like this>
{ “ids” : [ “1bdeaba0-7baf-4928-ac86-e1348e5f8984” ] }

Error message in gatling>
regex(“ids”:"([^"]*)).exists, found nothing

I kept hacking away at this and finally got an answer. Dumping the regex and opting to use JsonPath, I found an old post on this group page that had some links to references that helped me solve the puzzle.

https://groups.google.com/forum/#!searchin/gatling/jsonPath$20syntax/gatling/UcyEwKoydPU/R1jUUE1p8HwJ

For my case, the correct jsonPath to extract my guid was>

jsonPath("$.ids").saveAs(“postId”))

However, I still would like to find out if anyone has found a way to apply logback file (or any other config files) to Gatling when it is being run by the Java interpreter as a class file.

Cheers

  • Nadine

Sa regex à l’air fausse. Utiliser un tester de regex online.

Hi Nadine,

Gatling (and Logback) looks for their configuration files (gatling.conf/recorder.conf and logback.xml respectively) in the classpath.
Make sure that sourceSets.test.runtimeClasspath includes src/test/resources in the classpath and then add the configuration files in src/test/resources if they’re missing.

Cheers,

Pierre

Even i have trouble with pointing to logback.xml

Tried: -Dlogback.configurationFile=/Users/ct/gatling-gradle/performance/resources/logback.xml

but still it is not referring this file.

Yes, I am not so good at regex. What would be a good online regex checker for beginners?

There’s a lot of java regex testers out there, the one from Regex Planet is what I find myself usually using : http://www.regexplanet.com/advanced/java/index.html
There’s a direct to java.util.regex.Pattern’s Javadoc on the top right, which lists about everything that there is to be know about Java’s regexes character classes, etc…
Oracle’s lesson on Java Regexes is also a nice resource : http://docs.oracle.com/javase/tutorial/essential/regex/

Cheers,

Pierre

Thanks for the feedback.

I moved the logback and other configuration files directly under src/test/resources and set the classpath to use sourceSets.test.runtimeClasspath, but files in that directory still get ignored when Gatling task runs.
I also noticed in the console that there is a lot of noise about “multiple versions of sl4j found in classpath”. None of them seemed to mention scala or Gatling, but it makes me wonder if there could be a connection of some sort.

cool. sorry to have started a second topic in the same thread.