Limitations in the size of a variable?

Gatling (Open-Source)
1

I want to call a token service (with username and password), and get a token in return. The token consists of 900 characters and is 1 KB large.

Is this a problem using:

call1:

`
.check(jsonPath(“xxxx”).saveAs(“token”))

`

and ‘holding’ it in memory when in session and reusing it as this:

call2:

`

.exec(
http(“someCall”)
.get("/site/profile")
.header( “X-Token”, “${token}” )

`

I mean is this to large to handle by Gatling?

I do not have the chance to test this myself yet, but I thought I would ask if someone have had the chance to test large tokens before?

M

2

BTW: this is a JSON Web Token (JWT).

3

FYI, Atlassian has a JWT Gatling plugin: https://bitbucket.org/atlassianlabs/gatling-jwt

4

Ok, thanks. To bad it only supports http GET. I have some POSTs in my scenario as well requiring a token in the header.

exec(
         http("activateSomething")
           .post("/something/activate")
           .header("X-Token", "${memberID}")
           .body(StringBody("""{"offerId": "${item}", "membershipId": "${memberID}", "osName": "Android", "osVersion": "4.4"}""")).asJSON
           .check(jsonPath("$.resultCode").is("SUCCESS")))

5

It does not say that it only supports get. Did you try post? I am just wondering.

6

from bitbucket:

gatling-jwt

An extension to Gatling 2 to help send JWT-signed requests. Early stages, currently only supports GET requests.

7

@Magnus Were you able to find a workaround?

I think there is indeed a limit of some sort on variable size, but am not sure of the exact cutoff point. I suspect it’s embedded in a unit test somewhere.

Today I was working with a script and trying to inject a pre-fabricated JWT token to request header. My token was very similar to the token you described below – humungous.
Code looked something like this >
val foo = scenario( “bar” )
.header( “key”, “${blah}”)

.post( " mypost")
.body // remainder of the request omitted for brevity

Original plan was to set the token in a different class and then pull that variable into my request header.
However, when I ran my script, every single request using this header failed. Each had an error with text like “…attribute ${blah} not found”.

However when I hard-coded my token into the .header object, everything started working again.
Good results, but I feel dirty.

I’m looking now for a way to generate my own token from inside this class. It does not appear that a value this large can be safely passed between classes at runtime.

8

No, there’s no such limit from Gatling.

In Java:

  • there’s a limit for String literals (= hardcoded Strings) length, which is 65535 chars. This is because Java code is text that has to be parsed.

  • there’s a limit for String length, which is 2147483647 (maximum size of an array) as a String is backed by a char[]

9

My token is 521 chars, so it is nowhere near big enough to hit the Java limits.

What else could cause problems when passing string values into http header objects from a variable?

// in another class far away…
blah = “token string …rather long…500+chars”

// in the Scenario definition
.header( “key”, “${blah}”)

error has text like “…attribute ${blah} not found”.

10

ok, I think I stumbled across something.
I started from scratch with this header element. The compiler injected some extra text into my code, and this time I kept the change instead of deleting it. The “extra” text placed the char “s” in front of my variable reference.

this changed my .header statement to read like this>

"key" -> s"${jwtToken}" 



This value seems to be interpreted by the request the way I was expecting. 



What is this called and what does it do?
11

http://docs.scala-lang.org/overviews/core/string-interpolation.html

12

Thank you.

I was getting a bit confused about how to use Strings in regular Scala versus Strings in Gatling DSL.