robotframework / OldSeleniumLibrary

Deprecated Selenium library for Robot Framework
Apache License 2.0
13 stars 3 forks source link

SeleniumLibrary load not honoring the port change request #212

Closed spooning closed 9 years ago

spooning commented 9 years ago

Originally submitted to Google Code by jerry57 on 18 Oct 2011

Mac OS X 10.6.8 Python 2.6.1 RobotFramework 2.6.2 RobotFramework-SeleniumLibrary 2.8

Our testsuites load the seleniumlibrary as follows: Library SeleniumLibrary ${EMPTY} | ${EMPTY} | 4450

In the past this has worked without error but now we are seeing failures when suites are run back to back using different ports.

I looked in the selenium_server_log.txt and see that the default port is still being used.

Here is a snippet of the log: 15:59:14.925 INFO - OS: Mac OS X 10.6.8 x86_64 15:59:14.934 INFO - v2.3.0, with Core v2.3.0. Built from revision 13158 15:59:15.044 INFO - RemoteWebDriver instances should connect to: http://127.0.0.1:4444/wd/hub 15:59:15.045 INFO - Version Jetty/5.1.x 15:59:15.046 INFO - Started HttpContext[/selenium-server/driver,/selenium-server/driver]

I have also tried loading the library as follows and am getting the same error: Library SeleniumLibrary server_host=http://localhost:4450

spooning commented 9 years ago

Originally submitted to Google Code by @pekkaklarck on 19 Oct 2011

1) I don't see anything suspicious in the log snippet. How did you verify the library used wrong port?

2) Did you start Selenium Server as before the execution or using a keyword in the test data?

3) If you had exactly Library SeleniumLibrary ${EMPTY} | ${EMPTY} | 4450 the syntax is wrong. You should have pipes everywhere or nowhere.

spooning commented 9 years ago

Originally submitted to Google Code by jerry57 on 19 Oct 2011

You are correct, I wrote out the syntax for the import wrong. Here is the actual line we have been using for over a year now.

Library SeleniumLibrary ${EMPTY} ${EMPTY} 4480

How we found this was that when we run our regression suites for the web tests back to back, every other one was failing with "Connection refused". When I looked at the selenium_server.log, I found that it was using port 4444 instead of the port number we were assigning in the Library line. Because we sometimes run our testsuites stand alone, we have to import the library for each one. When they are run back to back, the first doesn't free up the port fast enough for the second to start on the same port. By us changing the port number each time, there aren't any problems. Only now they SeleniumLibrary seems to be not accepting the new port number. Even when I changed the testsuite to use the server_host= it still used port 4444 instead of the port number assigned.

If you would like, I will create a set of suites that will show this and the startup/shutdown conflict as well.

spooning commented 9 years ago

Originally submitted to Google Code by @pekkaklarck on 19 Oct 2011

1) In the log snippet you included the port 4444 is mentioned in instructions to WebDriver based clients. Was there something else that indicated that wrong port was used?

2) Having a simple example that demonstrates this problem would be great.

3) Have you considered starting the Selenium Server only once before execution and closing it afterwards? I've found this approach to be easiest in many situations. It also reduces the time you need to wait when the server is running.

spooning commented 9 years ago

Originally submitted to Google Code by jerry57 on 19 Oct 2011

Checkout issue #76 , it talks about the port conflict and why we use different ports.

spooning commented 9 years ago

Originally submitted to Google Code by jerry57 on 19 Oct 2011

I believe I have finally found where the problem lies and no it is not in the SeleniumLibrary code. Sorry about the confusion here. One of our new testers changed a base keyword that loads the library and consequently it wasn't passing the port info on the Library load. Hence selenium-server always used the default port.

My apologies to all about this. Please close the issue as non-reproducible.

Thanks, jer

spooning commented 9 years ago

Originally submitted to Google Code by @pekkaklarck on 19 Oct 2011

I understood why you needed to use different ports. What I proposed was avoiding restarts if possible. Anyway, closing this issue as the problem was in your test data.