Hello,
I’m new to gatling (using 2.0.0-M3a) and consider myself a beginner at scala. I’m trying to send a request, process the response and send that processed response as the body of the next request. I see the “processResponse” processor, but am not sure how to use it or if it’s even the correct solution for my use case… any help appreciated.
achap
Hi,
Have you read the tutorials?
You capture elements from the response using checks and generate request bodies with templates.
Also check out Gatling 2 page: https://github.com/excilys/gatling/wiki/Gatling%202#bodies
yes… i’ve read the tutorials… but I was still missing something. I noticed the “processResponse” Processor in the version 2.x docs and was thinking it might be what I’m looking for, but I’m not sure how to apply it. I also just ran across the Redis example which is different but think that might be a good place to start.
Maybe something like…
exec(
http(“request1”)
.post("/someResource1" )
.headers(myHeaders)
.body(ByteArrayBody(session => getRequest1BodyBytes(session)))
.check(bodyString.saveAs(“responseBody”)) // does using bodyString work for protobuf bytes?
)
.exec(
http(“request2”)
.post("/someResource2" )
.headers(myHeaders)
.body(ByteArrayBody(session => getRequest2BodyBytes(session)))
)
val getRequest2BodyBytes = (session: Session) => {
// make protobuf request object and return it in Array[Byte] format
// would also like to store a requestId in the session here if possible but not sure how to return both things
}
val getRequest2BodyBytes = (session: Session) => {
val myBytes = session(“responseBody”).as[String].getBytes
// turn into protobuf
// do stuff and return more bytes…
}
My response body from request1 is some binary data that is a protobuf. When generating request2 I need to turn the response content binary bytes from request1 into a protobuf object, do some stuff, create a new protobuf object (my new request body) and send that over the wire in the body of request2.
This seems to mostly work, but it currently looks like the protobuf im creating in the getRequest2BodyBytes isn’t happy with the bytes im feeding it.
That’s the first time you mention protobuf.
So then, yes, processResponse can be a proper solution for you problem.
What is the encoding you use in Gatling and your default JVM one? If it’s UTF-8, then the bytes → string → bytes roundtrip is supposed to be non destructive (except if there’s a bug in Gatling).
Note that current snapshot has a bodyBytes as well.
Cheers,
Stéphane
I must be doing something else incorrectly. I am receiving a content length of 189 bytes from the response of request1… using bodyString.saveAs to store it in the session, and after I pull it out of the session the size is 197. I am not changing the encoding settings… I think this means gatling is set to UTF-8… not sure about the JVM.
Any hints on how to use processResponse, and how much different is that solution from what I did?
Appreciate your time.
looks like the
“val myBytes = session(“responseBody”).as[String].getBytes”
line is returning bad stuff… the size of the String is sometimes 189 bytes sometimes 188 (I need 189), and the size after the getBytes call is a bit larger. I need the type to be Array[Byte] to turn it back into a protobuf.
I’d try the snapshot, but for now I’m using gradle to build stuff and it’s pulling down 2.0.0-M3a
ZincCompiler debug logs show what looks like encoding to be UTF-8, unless its being overridden some other place
looks like the
"val myBytes = session("responseBody").as[String].getBytes"
line is returning bad stuff... the size of the String is sometimes 189
bytes sometimes 188 (I need 189), and the size after the getBytes call is a
bit larger. I need the type to be Array[Byte] to turn it back into a
protobuf.
UTF-8 doesn't always use 1 byte per char, so that's entirely possible.
Then, there might be a bug, but then could you reproduce with snapshot?
I'd try the snapshot, but for now I'm using gradle to build stuff and it's
pulling down 2.0.0-M3a
Snaphots are hosted on Sonatype. I'm not familiar with gradle, but with
maven and sbt, you'd have to declare a new repository/resolver.
https://oss.sonatype.org/content/repositories/snapshots/
ZincCompiler debug logs show what looks like encoding to be UTF-8, unless
its being overridden some other place
Gatling uses the encoding defined in gatling.conf and default value is
UTF-8.
But then, you use "val myBytes = session("responseBody").as[String].getBytes"
and getBytes is a super crappy method (yeah Java) that uses the default JVM
encoding. This method should NEVER be used. You should be using
getBytes("UTF-8").
I tried things using the latest snapshot. By using the bodyBytes in the check to saveAs into the session and pulling out of the session as Array[Bytes] things worked for me… bodyString didn’t.
Glad that bodyBytes worked for you.
There might be a bug with bodyString, investigating.
Would you have some bytes dump so I can test with, please?
sure… see attached file. should be 189 bytes… not sure if the attachment/email process messed with it. let me know if I can add anything here… and thanks again for the help.
bytes.bin (189 Bytes)
Great, thanks!
I’ll check this tomorrow.
Cheers,
Stéphane
OK, so it turns out that I was wrong and that the UTF-8 bytes → String → bytes roundtrip is indeed destructive if it contains non-UTF-8 chars (which is your case).
Hopefully, there’s bodyBytes for your use case now.