Selenium driver instance persists if test is aborted on Jenkins

Question

Ok, so I am wondering how I can get my driver/browser sessions to properly exit if a test is aborted via jenkins. Locally, if I run my tests and abort them, the browser will quit properly. Via jenkins however, this does not happen. If I abort the job during the test phase where my tests are running on the selenium grid, the browser stays open - causing the node to still show up as being used because it did not pick up that the aborted job should have killed its browser session.

I have been messing around with cucumber hooks, but the more I think about it I am not sure if I can handle this with a hook since when ran locally this behavior does not happen. I am now thinking this needs to be either a setting on the selenium grid or jenkins.

My most optimal solution would be to use a hook like the one below that could tell if it was being run remotely and kill the session if aborted/passed/failed. But if there is any solution via jenkins or the selenium grid settings that would be great too! Thank you!

this.registerHandler('After', function (event, done) {
     // Some code to clear browser session 
    done();
});

Alsace

Answer 1

I dont think you need to do anything extra here at your client code.

The selenium Grid specifically has three parameters that are meant for these sort of cleanups.

• -browserTimeout in seconds : number of seconds a browser session is allowed to hang while a WebDriver command is running (example: driver.get(url)). If the timeout is reached while a WebDriver command is still processing, the session will quit. Minimum value is 60. An unspecified, zero, or negative value means wait indefinitely. Default: 0

• -cleanUpCycle in milliseconds : specifies how often the hub will poll running proxies for timed-out (i.e. hung) threads. Must also specify timeout option.Default: 5000 (5 seconds)

• -timeout, -sessionTimeout in seconds : Specifies the timeout before the server automatically kills a session that hasn't had any activity in the last X seconds. The test slot will then be released for another test to use. This is typically used to take care of client crashes. For grid hub/node roles, cleanUpCycle must also be set. Default: 1800

Using a combination of all the above 3 parameters, you can configure your node to automatically close orphaned browser instances and sessions.

This documentation is available within the selenium uber jar itself as command line documentation. You can refer to this SO answer to learn how to get it and see what other options are available.

There's some additional documentation related to timeouts on the Grid'2 wiki page here.

Hope that helps!

Gentile

Thank you for the reply! So looking in the grid settings, we have a browserTimeout: 16000, cleanUpCycle: 5000, timeout: 19000. We could try shrinking these settings, but I have watched the nodes and the browser persists until we finally restart the grid. – Alsace

@Alsace - Can you first please try reducing the values to a reasonable limit and see if that helps ? AFAIK it should help you clean up the stale browser instances and orphaned sessions. – Gentile

What would you consider reasonable settings? Even with these settings shouldnt we still see the browser get terminated in 19 seconds of inactivity? This is not the case :( – Alsace

Based on what you shared as your existing values, you have a browserTimeout value of 16000 seconds (very huge value, should be around 60 seconds) and a timeout value of 19000 seconds (again very huge value, should be around 45 seconds) Note that these values are in seconds but I think you are perhaps interpreting them as milliseconds ? – Gentile

Oh wow.. ok I totally get your point. I was under the impression it was ms. I will try to reduce these settings. One more question - what would be a good synergy between cleanUpCycle and timeout? It seems like if a browser is inactive (with no WebDriver commands running on it) it should be cleared immediatly – Alsace

The cleanUpCycle indicates how often the hub should run the polling. You can leave it as is, and you can try setting up a value of 45 seconds for your timeout and a value of 60 seconds for your browserTimeout. I guess it would be a trial and error approach before you arrive at an optimal value. But this should be a good start. Also please help accept my answer, if it answered your question. – Gentile

Answer 2

That is basically the same as wanting to do something after your abort execution locally, jenkins knows nothing about your grid it only builds code.

Consider having separate job that would be executed based on the results of execution of previous one, in it you could clean your env by killing stucked processes and maybe re-launching grid itself.

Showker

The only problem with this solution is that we have multiple teams running tests against the grid. I dont want another job to kill running tests, re launching the grid would do this. – Alsace