Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance restcomm-test.py to recycle browser tabs instead of using the same #67

Closed
atsakiridis opened this issue Mar 18, 2016 · 0 comments

Comments

@atsakiridis
Copy link
Collaborator

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:
    1. Finalize the restcomm web client library (so that we are unregistered),
    2. Send AJAX request to restcomm-test.py to notify that it needs to spawn a new browser
    3. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant