Hi,
I’m facing a problem in creating websocket request in gatling. the handshake is happening but its getting canceled very soon. can anyone please help me regarding this issue?
Hi,
Could you please check the guidelines on how to ask a question, in particular regarding providing a reproducer?
As is, your question is way to vague and doesn’t provide a means for other people to help you.
Regards
Hi All,
Sorry for the Vague question. i will try to explain the issue better
I’m currently testing the Thick client .net application. we are supposed to capture the SignalR requests from the application environment. But, we are unable to create a successful web socket request to capture this SignalR request. when we proxy it to fiddler to see the response it says “error=Handshake was canceled” . currently we are using gatling 3.4.2 version as we have license for the same Frontline version.
this is the issue we are facing.
Hello,
when we proxy it to fiddler to see the response it says “error=Handshake was canceled” .
Does this happen when the client is you actual client app (your web browser, I guess)? Or Gatling?
SignalR request
Honestly, we’re not familiar with SignalR here. SignalR is implemented on top of WebSocket, but I can’t find any specification of their protocol. Could you please provide a pointer to such specification?
currently we are using gatling 3.4.2 version as we have license for the same Frontline version.
Gatling Enterprise latest releases support Gatling from 3.3 to 3.7. Do you mean you’ve installed an old version quite some time ago and this version doesn’t support Gatling 3.5+? If that’s the case, you should really upgrade and test with Gatling 3.7.
Regards
Hi stepane ,
Is there a way to connect with you to speak about this issue in depth?
If you’re looking for a consulting contract to help you, please reach out here.
We only do direct assistance calls with our premium customers.
Hi @jmarly ,
I just had a quick look at your extension and it has a major flaw: it’s performing blocking operations in the shared Gatling execution threads.
See warning in the documentation:
Those functions are executed in Gatling’s shared threads, so you must absolutely avoid performing long blocking operations in there, such as remote API calls.
As a result, when you’re executing toCall.apply, you’re actually also stalling all the other virtual users that share this same execution thread.
You should either offload blocking operations to a dedicated thread pool, or switch to non-blocking IO if your library supports it.
Cheers
Thank you for checking this out Stéphane.
I have moved the SignalR API calls to be executed in their own thread pool to prevent blocking Gatling execution threads if/when SignalR calls are long.
1 Like