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

BrowserTimeout not working properly on grid in 2.5+ #5313

Closed
mattblaha opened this issue Jan 9, 2018 · 7 comments
Closed

BrowserTimeout not working properly on grid in 2.5+ #5313

mattblaha opened this issue Jan 9, 2018 · 7 comments
Labels

Comments

@mattblaha
Copy link

Meta -

OS:
CentOS 7
Selenium Version:
2.5+
Browser:
Chrome

Browser Version:
Chrome 63, chromedriver 2.34

Expected Behavior -

If a client connected to a grid fails to call driver.close(), the grid should free the slot and kill chromedriver and any running browsers when browserTimeout is reached

Actual Behavior -

Grid frees up the slot, but chromedriver and running browsers remain. If lots of tests fail to clean up after themselves, the grid eventually runs out of memory and crashes.

Steps to reproduce -

On CentOS 7 I start the grid like:

java -Xmx2048m -Xms2048m -jar selenium-server-standalone-3.4.0.jar -role hub -maxSession 20 -timeout 180 -browserTimeout 200

I start the chrome node like:

java -Xmx2048m -Xms2048m -Dwebdriver.chrome.driver=/usr/local/bin/chromedriver -jar /home/selenium/selenium-server-standalone-3.4.0.jar -role node -hub http://10.10.0.50:4444/grid/register -browser browserName=chrome,version=63.0.3,binary=/bin/google-chrome,maxInstances=9,platform=LINUX -maxSession 9

I have tried setting -enablePassThrough false, but the effect remains the same.

(Note with 3.4.0 in the example above, the browsers get killed as expected. Same command lines with newer versions, including 3.8.1, they fail.)

@mattblaha
Copy link
Author

Very simple test in ruby to reproduce, explicitly skipping driver.quit:

require 'selenium-webdriver'
require 'rspec/expectations'
include RSpec::Matchers

def setup
  @driver = Selenium::WebDriver.for(
    :remote,
    url: 'http://10.240.0.221:4444/wd/hub',
    desired_capabilities: :chrome) # you can also use :chrome, :safari, etc.
end

def teardown
  #@driver.quit
end

def run
  setup
  yield
  teardown
end

run do
  @driver.get 'http://www.google.com'
  expect(@driver.title).to eq('Google')
  @driver.save_screenshot('screenshot.png')
end

@p0deje p0deje added the C-grid label Jan 10, 2018
@mattblaha
Copy link
Author

The behavior in 3.9.1 seems to have changed further:

In 3.9.1:

  • setting -browserTimeout on the grid doesn't apply to the nodes. Using the config above, the gird shows browserTimeout 200 but the nodes show 0.
  • browserTimeout doesn't seem to apply at all. If I set it to 200 seconds, whereas before the slot would show free but the process would remain, now the slot never frees up, and the process remains open.
  • the global timeout value does eventually free the slot and the browser. With the config above, at 1800 seconds, eventually the browser dies and chrome gets freed up.

Maybe this is now more of a documentation issue. I am not sure what the intended behavior is at this point, the changelog doesn't indicate these behaviors should have changed.

@gmichels
Copy link

I was using 3.11.0 and was facing the same issue. Downgraded to 3.8.1 and at least the timeouts are properly propagated from hub to nodes.

I will see what happens when I hit a timeout on a node.

@diemol
Copy link
Member

diemol commented Sep 2, 2018

This seems to be a duplicate of #3064
@mattblaha @gmichels Could you please run the node in debug mode using version 3.14.0? You should be able that the configuration is correct.

@diemol
Copy link
Member

diemol commented Sep 9, 2018

Correcting myself, this is not entirely a duplicate.
Seems that commit d06e54a removed the use of browserTimeout by accident, we are working now to use the parameter again.

@mattblaha
Copy link
Author

Sorry I missed the first message here, but that's more or less what I suspected, great to hear someone's identified the specific commit.

@diemol
Copy link
Member

diemol commented Sep 13, 2018

This got fixed in 3f20f9f and it will be available in the next release.

@diemol diemol closed this as completed Sep 13, 2018
@lock lock bot locked and limited conversation to collaborators Aug 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants