Also make webrtc-client.html close the current tab once the call terminates. That will allow us to make sure there are no leaks in the browser/our code causing issues after some time of load testing
After a lot of back and fourth the logic is to just notify the restcomm-test tool from the webrtc web app (via Ajax HTTP) that the browser tab is about to close so that a new one can open by the tool. This gives us a robust way to maintain the pool of tabs, instead of changing the logic. Impacts:
webrtc-client.html: when the call ends:
Finalize the restcomm web client library (so that we are unregistered),
Send AJAX request to restcomm-test.py to notify that it needs to spawn a new browser
Close the browser window
restcomm-test.py: After all initialization completes and initial browsers are all spawned, then setup an http server listening for AJAX requests (no new thread, in the main thread) and spawning a new browser for the user provided in the request)
For reference here are some of the issues encountered in previous iterations:
Been trying to recycle the browser tabs as discussed to avoid leaks, etc by closing each tab after call scenario finishes. First tried monitoring how many chromes are open and if less than original number start new ones by incrementing or wrapping around if we have reached the last user from the pool. The problem here is that it takes some time until the PIDs are actually spawned and we might end up with more browsers than the initial count this is a problem as we might have registrations from the same user in more than 1 tabs
Then thought to maintain a PID per browser tab and only spawn a new tab if that user no longer has a tab. But here I confronted what I call the 'pid browser mess'. Turns out modern browsers don't play very well and when you open a new browser the pid you get back from the os doesn't say much, i.e. doesn't really represent the new tab. If you kill it it won't change a thing seems there's internal handling to make browsers as efficient and lots of tricks that end up ruining the expected behaviour.
Also make webrtc-client.html close the current tab once the call terminates. That will allow us to make sure there are no leaks in the browser/our code causing issues after some time of load testing
After a lot of back and fourth the logic is to just notify the restcomm-test tool from the webrtc web app (via Ajax HTTP) that the browser tab is about to close so that a new one can open by the tool. This gives us a robust way to maintain the pool of tabs, instead of changing the logic. Impacts:
For reference here are some of the issues encountered in previous iterations: