[ERROR] i.g.h.a.w.WsSendAction - Couldn't fetch open websocket: No attribute named 'gatling.http.webSocket' is defined

Gatling (Open-Source)
1

[ERROR] i.g.h.a.w.WsSendAction - Couldn’t fetch open websocket: No attribute named ‘gatling.http.webSocket’ is defined

I believe this (slightly confusing) error is thrown when you run out of sockets.
Looking for a confirmation.

2

This happens because you’re trying to send a message, but failed to open one in the first place.

3

I am running into the same problem. I’ve literally written hundreds of tests that use the HTTP part of Gatling. Now I need to test Node.js-based websocket endpoints (using SockJS). Before doing this, I wanted to set up a simple Node.js server to keep things simple and verify it works first. So I cloned: https://github.com/sockjs/sockjs-node/tree/master/examples/echo in order to have something simple to test Gatling against.

Then I wrote the following Gatling test which follows closely the example in ():

class EchoServerSimulation extends Simulation {

val httpConf = http
.baseURL(“http://localhost:9999”)
.acceptHeader(“text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”)
.doNotTrackHeader(“1”)
.acceptLanguageHeader(“en-US,en;q=0.5”)
.acceptEncodingHeader(“gzip, deflate”)
.userAgentHeader(“Gatling2”)
.wsBaseURL(“ws://localhost:9999”)

val scn = scenario(“EchoServerSimulation”)
.exec(
http(“Get”)
.get(“/”)
.check(status.is(200))
)
.pause(1)
.exec(
ws(“Connect WS”)
.open(“/echo”)
)
.pause(1)
.exec(
ws(“Send WS”)
.sendText(“hello”)
)
.pause(1)
.exec(
ws(“Close WS”).close
)

setUp(
scn.inject(atOnceUsers(1)).protocols(httpConf)
)
}

When I run the above, I get:

---- Errors --------------------------------------------------------------------

Couldn’t fetch open websocket: No attribute named ‘gatling.htt 2 (66.67%)
p.webSocket’ is defined

4

Check “Invalid Status Code 200” in the reports, and you’ll realize that this error happens on “Connect WS”.
When you open a WebSocket, you first send a get request over plain HTTP, and the server must respond with 101, which means “let’s upgrade the protocol and use WebSocket”. But here, you’re server responded with 200: OK, meaning that it didn’t understand that you wanted to do WebSocket and not plain HTTP. Then, as the WebSocket could not be opened, it could not be stored, causing the “Couldn’t fetch open websocket: No attribute named ‘gatling.http.webSocket’ is defined” errors on following requests.

I’ll investigate, but I suspect that SockJs uses some special request headers. Don’t use see anything in Chrome’s Dev Tool network panel?

A link to the “play chatroom example” would be nice.

Typesafe completely re-implemented the way Play is bootstrapped in Play 2.3. And it also seems that they just dropped the old samples (brilliant move) and didn’t port them to Activator. You can find it in Play 2.2 bundle: https://www.playframework.com/download#older-versions.

I guess we’ll have to write a new sample… :frowning:

5

The proper websocket url is not “/echo” but “/echo/websocket”.

See doc: https://github.com/sockjs/sockjs-client#connecting-to-sockjs-without-the-client

6

Hi Stephan,

I changed “/echo” to “/echo/websocket” and I was able to open the websocket without error. Seems odd/clunky to me at least that you have to append “websocket” to the request for SockJS to recognize it as such. I’ll read up more as well on SockJS and the WebSocket API to see if I can figure out why the initial http connection isn’t being upgraded to websocket. I’ll post whatever I find on this thread.

Thanks you for the quick response (our team is really smitten with Gatling – thanks for all the great work you and your team have put into it)!

Cheers,
Goodzilla

7

I changed "/echo" to "/echo/websocket" and I was able to open the
websocket without error. Seems odd/clunky to me at least that you have to
append "websocket" to the request for SockJS to recognize it as such. I'll
read up more as well on SockJS and the WebSocket API to see if I can figure
out why the initial http connection isn't being upgraded to websocket.
I'll post whatever I find on this thread.

That's not about WebSocket, but about SockJS. SockJS is not a WebSocket
implementation, but a framework with fallback strategies (if WebSockets are
not supported, try long-polling, etc...). I guess the different modes are
bound to different paths.

Thanks you for the quick response (our team is really smitten with Gatling
-- thanks for all the great work you and your team have put into it)!

Thanks for your kind words :slight_smile: