Gatling throws exception on receiving specific messages on websockets

App I’m running load tests against is using STOMP over websocket protocol.
I’m getting this exception from time to time:

10:14:02.119 [GatlingSystem-akka.actor.default-dispatcher-6][ERROR][BaseActor.scala:33] i.g.h.a.a.w.WsActor - Actor io.gatling.http.action.async.ws.WsActor@4a6c7aef crashed on message Some(OnTextMessage(h,1508321642119)) java.lang.IllegalArgumentException: Actor io.gatling.http.action.async.ws.WsActor@4a6c7aef doesn't support message OnTextMessage(h,1508321642119) at io.gatling.core.akka.BaseActor.unhandled(BaseActor.scala:38) at akka.actor.Actor.aroundReceive(Actor.scala:515) at akka.actor.Actor.aroundReceive$(Actor.scala:512) at io.gatling.core.akka.BaseActor.aroundReceive(BaseActor.scala:23) at akka.actor.ActorCell.receiveMessage(ActorCell.scala:527) at akka.actor.ActorCell.invoke(ActorCell.scala:496) at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257) at akka.dispatch.Mailbox.run(Mailbox.scala:224) at akka.dispatch.Mailbox.exec(Mailbox.scala:234) at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Looks like it could be caused by a heartbeat message coming from the server, but I’m not 100% sure.
What is a proper way to handle this case?

The main problem is, that user which encounters this kind of thing hangs forever instead of finishing its scenario in time specified (I’m using .during() loop).

I’m using Gatling 2.3.0

Frankly, no idea, sorry.
The WebSocket support is in the process of being completely revamped for Gatling 3.

And when is Gatling 3 expected to be released?

Most likely 2018 Q1.
Biggest items in the roadmap are HTTP/2 support and finish WebSocket revamping (binary frames support, async checks).
Best way to make it happen quickly is to contribute.
Then, if you want us to quickly work on a specific feature and get stable Gatling 3 preview version, you can contract with us for frontLine.

Thanks for info!

Just in case anyone has similar problems, which does not seem likely however =)
In my particular case, enclosing one of the test blocks into exitBlockOnFail seems to have helped. Probably it just minimized the probability of ever getting this heartbeat message (looks like it is only sent if there are no requests/responses either way).

@Katerina Can you please post your example?

Hi!
What kind of example would you like to see?
I cannot share any requests details and similar info.
In general, here’s what i do:
If there is a request, which needs some info received in responses earlier in the scenario, I put this request into exitBlockOnFail{chain} block:

.someRequest
.exitBlockOnFail {
anotherRequest(dataReceivedInEarlierResponses)
.anotherAnotherRequest(moreDataReceivedInEarlierResponses)
}

Thus, if some of the requests in the block has failed, there is no sending requests with no data or some corrupted data, and there is no fruitless waiting when no meaningful requests were sent.
In my case it pretty much corresponds to what actual application does: in most cases it won’t send anything if it has not received necessary data.

Btw, this issue was encountered in Gatling 2.3 and I have no idea if it is relevant to Gatling 3 (probably not, as websocket part was rewritten afaik). I haven’t finished migrating my code, and I’m rather far from running any actual tests which could bump into such situations.