Incorrect handling of "port 0" in Selenium Grid setup

[vflegel-sib]

Background:

• Under Linux and Windows, bind()-ing to network port 0 assigns the application a free port from the dynamic port range.
• I opened a similar ticket (Add support for "port 0" dynamic port allocation #1292) but it was rejected because I only referred to deprecated RC tests, but the described behaviour also affects WebDriver tests.

Test setup:

• Selenium server standalone version 2.48.2
• CentOS 7
• Java 1.7.0_91

Issue description:

• In a Selenium Grid setup, nodes launched using option -port 0 will correctly listen to a random free port assigned by the OS but will wrongly register on the hub using port 0 instead of the effective port they are listening on.

Example:

While having a hub listening on port 4444, launch a node with a nodeconfig.json similar to:

{
  "capabilities":
      [
        {
          "browserName": "firefox" ,
          "maxInstances": 2,
          "seleniumProtocol": "WebDriver"
        }
      ],
  "configuration":
  {
    "proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy",
    "maxSession": 2,
    "port": 0,
    "host": 127.0.0.1,
    "register": true,
    "registerCycle": 5000,
    "hubPort": 4444,
    "hubHost": 127.0.0.1
  }
}

lsof will show that the node process listens on a random port offered by the OS, but the Grid console will show the node as being registered with port 0 instead of the effective listening port:

nodeConfig:nodeconfig3.json
port:0
hubConfig:/opt/selenium/hubconfig.json
servlets:[]
host:127.0.0.1
cleanUpCycle:5000
browserTimeout:0
hubHost:127.0.0.1
registerCycle:5000
capabilityMatcher:org.openqa.grid.internal.utils.DefaultCapabilityMatcher
newSessionWaitTimeout:-1
url:http://127.0.0.1:0
remoteHost:http://127.0.0.1:0
prioritizer:null
register:true
throwOnCapabilityNotPresent:true
nodePolling:5000
proxy:org.openqa.grid.selenium.proxy.DefaultRemoteProxy
maxSession:2
role:node
jettyMaxThreads:-1
hubPort:4444
timeout:300000 

• No submitted Webdriver, RC, etc. tests will be able to run on this wrongly registered node.

Also this incorrect behaviour seems to affect all the possible use cases of Selenium (see also the closed ticket #1292 )

Kind regards,

Volker