ERROR: connect ECONNREFUSED

[albertoacn]

I have a job in Travis CI which is using wdio.conf.js to run several tests in Saucelabs, the configuration was working fine until it started failing intermittently several weeks ago. This is the error message:

ERROR: connect ECONNREFUSED 127.0.0.1:4445

I have tried adding to the tunnelDomains in Saucelabs config ‘localhost’ and ‘127.0.0.1’, also I have added Travis job number as tunnelIdentifier. Even I constrained the concurrency of the job, but none of these changes have worked.

I am pretty sure that this should be a trivial thing, but I have not found any reason why this started failing, so I thought that maybe this is a malfunction in wdio-selenium-standalone-service.

[christian-bromann]

Can you provide a reproducible example?

[albertoacn]

Hi Christian, thanks for replying.
It is reproducible when we have 2 concurrent jobs in Travis, i.e. two concurrent jobs using Saucelabs with the same configuration. Thats the reason I already constraint the concurrency to 1, but it still fails sometimes anyway.

[christian-bromann]

Why do you need this service when you run your tests on SauceLabs anyway?

[albertoacn]

Well, we have it in wdio.conf.js to run either local or in Saucelabs, this is the part where we contemplate both:
...
services: [ 'selenium-standalone', 'firefox-profile' ],
...
if (process.env.SAUCE_USERNAME && process.env.SAUCE_ACCESS_KEY) { config.services.push('sauce');
...
When running in local it works fine. Would you suggest to push selenium-standalone service only if it is not running in Saucelabs?

[christian-bromann]

@albertoacn can you try to keep the current setup but add:

if (process.env.SAUCE_USERNAME && process.env.SAUCE_ACCESS_KEY) { 
    config.protocol = 'http'
}

[albertoacn]

Thanks for this first try, but it still fails.
To be more accurate if we are running 2 jobs, only one will fail (the one which starts a bit earlier).

[albertoacn]

@christian-bromann is there any advance in this? It is reproducible every time. Thanks.

[BenoitAverty]

This is the config I use to start the selenium standalone service in local only :
services: ci ? ['sauce'] : ['selenium-standalone']

the ci var is defined as const ci = process.env.CI && process.env.CI === "true"

You can use a similar setup with sauce variables to avoid starting a local selenium in travis.

[AronNovak]

I experienced this at a VM due to this:
SeleniumHQ/selenium#6605

root@localhost:~# /usr/bin/java -Dwebdriver.chrome.driver=/root/wdio/node_modules/selenium-standalone/.selenium/chromedriver/2.43-x64-chromedriver -Dwebdriver.gecko.driver=/root/wdio/node_modules/selenium-standalone/.selenium/geckodriver/0.23.0-x64-geckodriver -jar /root/wdio/node_modules/selenium-standalone/.selenium/selenium-server/3.141.0-server.jar
07:44:23.376 INFO [GridLauncherV3.parse] - Selenium server version: 3.141.0, revision: 2ecb7d9a
07:44:23.604 INFO [GridLauncherV3.lambda$buildLaunchers$3] - Launching a standalone Selenium Server on port 4444
2018-11-28 07:44:23.720:INFO::main: Logging initialized @842ms to org.seleniumhq.jetty9.util.log.StdErrLog
07:44:24.340 INFO [WebDriverServlet.<init>] - Initialising WebDriverServlet
Exception in thread "main" java.lang.IllegalStateException: Insufficient configured threads: required=3 < max=3 for QueuedThreadPool[qtp710714889]@2a5ca609{STARTED,3<=3<=3,i=3,q=0}[ReservedThreadExecutor@ef9296d{s=0/1,p=0}]
        at org.seleniumhq.jetty9.util.thread.ThreadPoolBudget.check(ThreadPoolBudget.java:155)
        at org.seleniumhq.jetty9.util.thread.ThreadPoolBudget.leaseTo(ThreadPoolBudget.java:129)
        at org.seleniumhq.jetty9.util.thread.ThreadPoolBudget.leaseFrom(ThreadPoolBudget.java:181

[abdullahawara]

This issue is weird, I experienced this issue when running tests locally after changing my timeouts in
wdio.conf.js to be waitforTimeout: 70000
and in my test code:
const value = browser.waitUntil(() => doSomethingInPromise(), 20000, 'message', 20000)

More Info:

• package.json :

{
  "name": "wdio",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "./node_modules/.bin/wdio",
    "headless": "headless=true ./node_modules/.bin/wdio"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@babel/core": "7.3.4",
    "@babel/plugin-transform-runtime": "7.3.4",
    "@babel/preset-env": "7.3.4",
    "@babel/register": "7.0.0",
    "@babel/runtime": "7.3.4",
    "@wdio/cli": "5.6.4",
    "@wdio/junit-reporter": "5.6.4",
    "@wdio/local-runner": "5.6.4",
    "@wdio/mocha-framework": "5.6.4",
    "@wdio/sauce-service": "5.6.4",
    "@wdio/spec-reporter": "5.6.4",
    "@wdio/sync": "5.6.4",
    "@wdio/selenium-standalone-service": "5.6.4",
    "webdriverio": "5.6.4",
    ...
  },
  "dependencies": {}
}

• wdio.conf.js :

    runner: 'local',
    services: ['sauce', 'selenium-standalone'],
    specs: [...],
    exclude: [...],
    maxInstances: 10,
    capabilities: [{
        browserName: 'chrome' // it happens also on firefox
        maxInstances: 30,
    }],
    waitforTimeout: 70000,
    connectionRetryTimeout: 90000,
    connectionRetryCount: 3,
    framework: 'mocha',
    reporters: [
        'spec',
        ['junit', {
            outputDir: __dirname + '/junit_reports',
        }],
    ],
    mochaOpts: {
        ui: 'bdd',
        compilers: ['js:@babel/register'],
        timeout: 99999999,
    },
    ...

• I tried killing selenium-standalone processes (didn't work).
• closing terminal and opening a new one didn't help.
• It happens constantly on chrome and firefox (headless and normal).

I've been running hundreds of successful and failing tests over 3 days before this happened. It seems a communication issue with selenium-standalone to me.