But these requests are executed by different users in different sessions. It is problematic for my scenario because I have key-value retrieved from previous responses and saved in user session storage.
So I could use this approach only if there is a way to share key-value between user sessions.
I need to execute second request concurrently with first one. Exec() calls request synchronously which means it will complete getting response on this request from server.
I’m working with Ajax application in my case and requests must be asynchronous.
Answering on question: What would the behavior of such pauses be?
Let’s consider simple UI with two buttons. First button binded to long running GET request, let’s call it ‘run/start’. The second button is ‘cancel’ and it is binded to another request which can ‘cancel’ already running process.
End-user starts a long-running process and he/she can cancel/stop process pressing ‘cancel’ button after several seconds from pressing first button.
So test scenario looks like two asynchronous calls with pause between it.
In a nutshell, I do not believe that stock Gatling DSL can support this scenario. Typically, Gatling waits for a request to finish before continuing with the execution. You want to violate this principle.
The only way you could simulate this, in theory, if Gatling supports it, is to specify a per-request timeout. If the default Gatling request timeout is 60 seconds, then you would have to specify a timeout of 5 seconds for that request. Then, after 5 seconds, the request would “fail” and you would initiate the cancel request.
But that’s a hack. It messes with your reports. And it sounds more like functional testing than load testing. Pulling off this use case will require you to write custom code, I’m afraid. And I can’t tell you what that code would look like, I can only tell you that it will probably not be Gatling DSL.