Hello XI support
We are having troubles with Selenium perl scripts where they are running OK once but create troubles with countless Firefox windows opened and never closed when scheduled to run actively on remote Selenium server (many different scripts).
Is there way to schedule them never to run same time (either passively from the remote selenium server or somehow actively with XI)?
- so that there is only 1 script runs at a time and never multiples, which creates troubles?
Thank you
Could we cron Selenium scripts passively at client end
Re: Could we cron Selenium scripts passively at client end
Have you identified why certain Selenium RC Server instances are never properly closed? That would be step 1 in my opinion. Even if you scheduled your tests to not run simultaneously, you will still have tests getting timed-out when one of the instances gets stuck.
Yes and no. If you're using a distributed setup via Selenium Grid you can implement a queue, but this could potentially cause your tests sent from Nagios XI to time out while they sit in queue and return critical. The solution at that point would be two-fold and beyond anything we've ever really documented internally.dlukinski wrote:Is there way to schedule them never to run same time (either passively from the remote selenium server or somehow actively with XI)?
- so that there is only 1 script runs at a time and never multiples, which creates troubles?
Former Nagios employee
https://www.mcapra.com/
https://www.mcapra.com/
Re: Could we cron Selenium scripts passively at client end
This is more like Firefox not closing when running multiple checks same time, but closing with 1 check at a time. So eventually we get dozens of Firefox session opened and Selenium process crashes (disappears)mcapra wrote:Have you identified why certain Selenium RC Server instances are never properly closed? That would be step 1 in my opinion. Even if you scheduled your tests to not run simultaneously, you will still have tests getting timed-out when one of the instances gets stuck.
Yes and no. If you're using a distributed setup via Selenium Grid you can implement a queue, but this could potentially cause your tests sent from Nagios XI to time out while they sit in queue and return critical. The solution at that point would be two-fold and beyond anything we've ever really documented internally.dlukinski wrote:Is there way to schedule them never to run same time (either passively from the remote selenium server or somehow actively with XI)?
- so that there is only 1 script runs at a time and never multiples, which creates troubles?
Re: Could we cron Selenium scripts passively at client end
Just to clarify, you're saying that the Selenium server is simply being overwhelmed by the number of test cases being sent simultaneously?
There isn't a very good way to mitigate this within Nagios XI aside from adjusting your check intervals for each service. Which is to say there isn't any logic within Nagios Core to say "please don't run these checks at the same time".
You might consider expanding your environment to a Selenium Grid to distribute these test cases.
There isn't a very good way to mitigate this within Nagios XI aside from adjusting your check intervals for each service. Which is to say there isn't any logic within Nagios Core to say "please don't run these checks at the same time".
You might consider expanding your environment to a Selenium Grid to distribute these test cases.
Former Nagios employee
https://www.mcapra.com/
https://www.mcapra.com/
Re: Could we cron Selenium scripts passively at client end
Actually not exactly overwhelmed. We run single instance of selenium jar.mcapra wrote:Just to clarify, you're saying that the Selenium server is simply being overwhelmed by the number of test cases being sent simultaneously?
There isn't a very good way to mitigate this within Nagios XI aside from adjusting your check intervals for each service. Which is to say there isn't any logic within Nagios Core to say "please don't run these checks at the same time".
You might consider expanding your environment to a Selenium Grid to distribute these test cases.
Case 1 (where we need correct scheduling as asked initially)
- multiple scripts connecting to essentially same portal, but different services under it. Firefox would timeout without finishing the script. Never logout (same credentials used in multiple scripts and although Firefox windows are different this does not seem to work). So many firefox browsers open and never close. This eventually kills the Selenium Server process
Case 2 (not sure about this one at all)
- multiple scripts 1 script = 1 portal. not related otherwise. Scripts would finish correctly and close Firefox when run "passively" only once for each of the checks.
However when same few scripts (again different portals) made Active and scheduled every 10-15 min each, same trouble happen. firefox does not get closed, open browsers count build up and eventually kills Selenium server
Re: Could we cron Selenium scripts passively at client end
Unfortunately neither of those problems are solvable from the Nagios XI end of things.
They are perfectly solvable from the Selenium end of things by hardening your test cases to account for the race conditions (which would involve first identifying them). Maybe that involves shorter timeouts, destroying browser sessions, etc.
They are perfectly solvable from the Selenium end of things by hardening your test cases to account for the race conditions (which would involve first identifying them). Maybe that involves shorter timeouts, destroying browser sessions, etc.
Former Nagios employee
https://www.mcapra.com/
https://www.mcapra.com/
Re: Could we cron Selenium scripts passively at client end
Thank youmcapra wrote:Unfortunately neither of those problems are solvable from the Nagios XI end of things.
They are perfectly solvable from the Selenium end of things by hardening your test cases to account for the race conditions (which would involve first identifying them). Maybe that involves shorter timeouts, destroying browser sessions, etc.
Please close this case now (we've got our answers)