Websocket API questions

Hi,

I want to do something that seems relatively simple to me using the websocket API.

Given a stream of messages like

:

I want to check that messages from each user come with continuously increasing sequence numbers (1,2,3,…) not (3,1,2,…) or (1,2,4,…). I want to continue run this check for as long as the scenario runs, and I do not know how many messages will come. I asked the same question on SO, but did not yet get any answers: http://stackoverflow.com/questions/35361878/stateful-checks-in-gatling-websocket-scenario

First of all: how do I arrange for the check to be active until closed explicitly and accept an unbound number of messages? Will the following work to check if all messages are “ok” until the ws is cancelled?

.exec(ws(“WS”)
.open("/indexWS?userId=${userId}&accessToken=${accessToken}")
.check(wsListen.within(Int.MaxValue.seconds).until(Int.MaxValue).message.find.is(“ok”))

)
// some other stuff happening

.exec(ws(“WS”).cancelCheck)
.exec(ws(“WS”).close)

Second: how do I keep a state of type Map[String, Int] to remember the last sequence number for each number? It seems that the WS API only allows saveAs of type String?

Thanks in advance for your help,

Rüdiger

Hi Rüdiger,

Sadly, that’s not currently possible.
We’re in need of feedback on the WebSocket API which is currently experimental.
Yours makes sense, and we’ll take it into account when we’ll redesign it in a future version (not 2.2 sadly).

Regards,

Hi Stéphane*,*

I managed to get it to work by just using a synchronized global dictionary from session to websocket state, and then doing a “transform” just for the side effect.

.check(wsListen.within(1.day).expect(0 until Int.MaxValue).message.find.transform(onWebSocketMessage _))

At the end of the scenario the global state is read out to get the result. I was hoping for something a bit more pretty, but this works for now.

Cheers,

Rüdiger

Thanks for your feedback! And glad you were able to find a workaround.
We’ll redesign the WebSocket API in 2016 after 2.2. Anyway, we’ll need a great API for full-duplex protocols, as we’ll want to support HTTP/2 at some point.

Cheers,