.exec(session => {
val mySessionVariable = session.getAttribute(“mySessionVariable”)
session
})
For clarity, is the first expression meant to be wrapped in an .exec(session => { } ) to work? It’s not working for me.
More importantly, when I dump the session
.exec(session => {
println(session)
session
})
I don’t see values in there that I know are there. Once logged in, some variables are stored in the session. I’d expect those to be printed when I print the session info.
All I see when I print
a map containing gatling.http.referrer, gatling.http.cookies, and gatling.core.timeShift
none of which contain the actual variables stored in the session.
Hi Stephane - Thanks again for your quick response. See my responses and the info you asked for
No. It’s not intended to be used everywhere, but only where the doc says it can, as it’s parsed and transformed into the second form.
I am still not clear on this. If i expect values in the session, then when I am executing a request, should I be able to grab that value from the session to use as parameters?
provided I have stored age and height in the session before hitting this request under those keys respectively.
So that means that you think they are here, but they actually don’t
Yes, they should be there
I recorded a very simple script, logging into an application using Spring Security which stores it’s object in session once the user has been authenticated. After logging in, I dump the contents of the session on a page. I am able to verify the values are there. For good measure, I also put a value (current time stamp of the request), into the session. Then I logout.
So there steps of the scenario I recorded are:
Request a secure page
Redirects to login page
User logs in
Sees the secure page (which just dumps the session info)
Here is what Gatling console reports (when I dump the session after logging in. NOTE: there is no SPRING_SECURITY_CONTEXT or the time_now i manually added) https://gist.github.com/4512367
Huh? I think there’s a big misunderstanding here: the Gatling user’s session has nothing to do with the java HttpSession!
The first one lives on the client side in Gatling, while the second one lives on the server side in your webapp.
In order to inject data into Gatling’s user session, you either have to use a Feeder, use a check with saveAs, or hack the session with a function.
See respective Feeder and Check documentation.
Oh I see. That was really a misunderstanding on my part. For whatever reason, I thought that was referring to the http session on the server.
Using feeders, is it at all possible to get hold of the http session on the server? I briefly taken a look, and I don’t think that can be done, but I still wanted to ask
Also, does using jdbc feeders have an negetive impact on performance, compared to the other feeders? i.e. is it preferable to feed in a file if you can than trying to hit the database?
Using feeders, is it at all possible to get hold of the http session on
the server? I briefly taken a look, and I don't think that can be done, but
I still wanted to ask
Nope, no way
Also, does using jdbc feeders have an negetive impact on performance,
compared to the other feeders? i.e. is it preferable to feed in a file if
you can than trying to hit the database?
Not really as the whole feeder content is pull from the database on start
up, not record per record during the run.