Gatling throws exception on receiving specific messages on websockets

[Katerina Stepanova]

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).

[Katerina Stepanova]

I'm using Gatling 2.3.0

[Stéphane LANDELLE]

Frankly, no idea, sorry.

The WebSocket support is in the process of being completely revamped for Gatling 3.

Stéphane Landelle

GatlingCorp CEO

slan...@gatling.io

On Wed, Oct 18, 2017 at 1:03 PM, Katerina Stepanova <rovei...@gmail.com> wrote:

I'm using Gatling 2.3.0

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Katerina Stepanova]

And when is Gatling 3 expected to be released?

[Stéphane LANDELLE]

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.

Stéphane Landelle

GatlingCorp CEO

slan...@gatling.io

On Thu, Oct 19, 2017 at 1:28 PM, Katerina Stepanova <rovei...@gmail.com> wrote:

And when is Gatling 3 expected to be released?

--

[Katerina Stepanova]

Thanks for info!

[Katerina Stepanova]

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).

[Aniruddha Dongre]

@Katerina Can you please post your example?

[Katerina Stepanova]

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.