Is there any plan to support async checks in web sockets? The current implementation supports web sockets focused on a request/response pattern which can cause message loss if a message arrives in between checks.
We basically need to be able to guarantee that all messages that arrive at the websocket actor are published into the active session.
Given the current FSM it would be fairly easy to implement a WhenListening that doesn’t reset the check and caches the messages until a “reconcile” type message is received. I am interested in hearing your thoughts on this.
Given the current FSM it would be fairly easy to implement a WhenListening that doesn’t reset the check and caches the messages until a “reconcile” type message is received.
If you say so
So I have been giving this some thought and it seems a bit silly to me to have two different modes of supplying checks to a web socket. What do you think about modifying the existing web socket flow to capture messages missed when there isn’t a check in place and when you set the next check it can optionally take into account the cached messages or discard them and only process new ones?
I am assuming that we should keep the the existing behavior and would have to discard cached messages. Even though this feels like a bug to me as I am not sure that people are aware that they can miss messages if a check isn’t in place at the moment a message arrives.
Hi! Jesse have you worked on this at all? I’m interested in such an approach as well. The issue I’m facing is that I would like to take a more reactive/async approach to socket handling. My backend has an engine that will send messages representing updates in the state which should impact the actions I take in my simulation. Let me try to explain.
Here’s a simplified example:
State A => loop forever and send Message A to the server every 10 seconds
State B => loop forever and send Message B to the server every 10 seconds
At any point in time, the server might decide to change from state A to B which should be acted on in the simulation. Sending a message with a check doesn’t seem to be enough because a change state might come after 1…N iterations (or never) plus it can get cumbersome for more than 2 states.
The problem is way more complex that you think and I can assure you that words like “basically” and “fairly easy” don’t reflect what needs to be done.
Believe me, if it was that easy, we would have done it already…
If checks are async, it means the main flow continues and state (Session) can be updated, for example, because other HTTP requests perform checks, or whatever user can think of.
When this happens, we’ll have multiple concurrent Sessions for the same virtual user.
Reconciling is extremely complicated. It’s not just a matter of matching messages, you also have to deal with timeouts, then out of bands responses, cancellations, etc.
Moreover, people have a very hard time figuring when to trigger reconcile. Just check how many times people ask on this mailing list why with .resources(req1.check(check1), req2), req2 doesn’t always see the result of check1.
All in all, supporting async checks would requires a lot of work, possibly dropping Akka for Gatling 4.
I suspect that even reviewing contribution tentatives and pointing to all the things that wouldn’t work would be very time consuming.
This is just not something we can spend time at the moment outside of a contract.
I am not saying that I could get it working in a day or two but I don’t think that it is in the realm of a few weeks. As far as I can tell the problem could be solved by the following
- add support to submit a check without sending a message and have it not fail on timeout. I actually can’t tell if it would fail on timeout at the moment. Hard to know by just reading the code in github
- add support while idle to cache messages in the wsactor by re-entering the idle state with the additional data
- add support to use cached messages when a check is submitted
The whole idea is the wsactor can cache messages and at some point the session can ask to get those messages checked. It isn’t an async check as much as it is a delayed check. We could also add to support to the check to ignore cached messages.
Is there something that I am missing? I am really trying to understand the requirements and issues before I attempt to add this feature. Not sure what you would suggest the DSL would look like? Maybe just ws(“Check for messages”).await(100 milliseconds)(check1)
In gatling 2.3 we added binary message support as well as fixed a few bugs in the reconcile flow. Gatling 3 websockets have been cleaned up significantly from what was existing. I would like to attempt to add this feature so that everyone can benefit from it.