Hi there, I have a Node.js webinar application. For months now I had been seeing intermittent crashes here and there. I finally figured out the root issue causing the errors.
Essentially, any time an attendee joined a webinar, a call was made to OpenVidu.fetch() to retrieve the list of active sessions. This worked well enough for small webinars but when a user was running a webinar with 50+ attendees that would all join around the same time (and sometimes much, much more than that), all these simultaneous calls to OpenVidu.fetch() would cause request timeouts/application crashes.
After doing a lot of load testing, I was finally able to pinpoint the issue. I solved the problem by essentially caching the active sessions in memory (similar to the OpenVidu Node.js example) and then calling OpenVidu.fetch() only when needed. This seems to work well enough and I’m not seeing the crashes anymore thankfully.
However, because my application runs on multiple nodes/server instances, I’m now seeing some weird edge cases where one node/instance has the most recent list of active sessions but another node/instance doesn’t. So for example, one node/instance will have an older list of active sessions compared to another node/instance. This could lead to weird things like trying to call session.createConnection() on a session that was already closed.
So essentially, my question is: Is there a recommended way to go about keeping track of active sessions without constantly calling OpenVidu.fetch()? Am I already going about it the “correct” or “recommended” way?
Hope what I’m asking makes sense. Thanks!
Hello,
OpenVidu API is a RESTful service. Access to the state of entities may change between requests, and this is normal given the nature of the system. Besides that, if the application generates a great amount of creation/deletion of entities in a very short timespan, then the state will change very quickly and different requests performed “at the same time” may return different results.
OpenVidu server SDK’s (openviud-java-client and openvidu-node-client) were designed with a polling strategy rather than a pushing strategy to be as similar as possible to the REST API underneath. And method fetch allows developers to fine-tune the number of requests and their timing to maximize efficiency according to each application and use-case. So answering your question: yes, the proper way to consume OpenVidu REST API is precisely to adjust and optimize the calls to fetch method.
And of course the recommended way to react upon unexpected operation statuses (for example, trying to generate a new Connection for a Session that was already closed) is simply to make your application resilient to those situations. If one of your backends thinks a specific session is active and ready to create new Connections, but the session is closed during the time the backend sends the request and openvidu-server receives it, then your backend should have the proper logic to handle the 404 error that will return. Nothing is wrong: your app must simply consider that local in-memory information may not be 100% up to date with respect to the “real” information in openvidu-server.
Best regards.
@pabloFuente Thanks, I had assumed as much at this point but I just wanted to double check and see if I was missing something.