WebSocket wsAwait hangs indefinately, if connection closed

I have following scenario:

val scn = scenario("WebSocket")
  .exec(ws("Connect WS").open(""))
  .exec(ws("Sending query")
         .sendText(session => query())
  .exec{ session =>
  .exec(ws("Close WS").close)


During execution 1st query executes successfully, but rest 4 are times out. That’s expected failure.

The problem, is that this Gatling method couldn’t process closed connection:


So, I expect, that it would wait up to 300 seconds. And if connection is not getting closed, that’s exactly, how it works.

But, if connection get closed, then this method never finish execution, and keep running for hours.
Here is what I see in the console after few hours:

2015-08-20 08:38:32 56467s elapsed
---- WebSocket -----------------------------------------------------------------
[##############------------------------------------------------------------] 20%
waiting: 0 / active: 4 / done:1
---- Requests ------------------------------------------------------------------

Global (OK=12 KO=4 )
Connect WS (OK=5 KO=0 )
Sending query (OK=5 KO=0 )
Sending query Check (OK=1 KO=4 )
Close WS (OK=1 KO=0 )
---- Errors --------------------------------------------------------------------
Websocket ‘gatling.http.webSocket’ was unexpectedly closed wit 4 (100.0%)
h status 1006 and message Connection was closed abnormally (th…

So, this seems like a bug in Gatling method. Or am I not understand something about the .check(wsAwait.within(300) method?

I’m using Gatling 2.1.7.

So, my main question is how to write a code (I guess that should be a .check),
so it

  1. wait for the message up to TIMEOUT
  2. OR until WebSocket gets closed

1st part can be done by wsAwait.within(300), but how I do 2nd part - how I consider WebSockets getting closed?

This is a known issue: https://github.com/gatling/gatling/issues/2601


Is issue #2241 will offer alternative way to handle the above scenario:https://github.com/gatling/gatling/issues/2241


I hate to necropost a year old thread, but has there been any further work addressing this? It seems like the problem is known, but is there any solution to save a simulation that gets stuck this way?

At a minimum, it would be helpful to have a means to kill a simulation and still get the results printout (sending sigint kills the simulation, but doesn’t make the results printout). Any solution or workaround would be very helpful.

The WebSocket support will be rebooted in Gatling 3.
WIP happens here: https://github.com/gatling/gatling/issues/3071

Current state should have this fixed, but it’s only available as a preview for our Support offer subscribers.
It will only make it into the OSS branch when we’ll release Gatling 3, at least in one year from now.

Hi there,

Sorry to necropost (again) this more-than-year-old thread. Are there any news about this? According to https://github.com/gatling/gatling/issues/3071 last commit was a few months ago.