Parallel ChromeDriver / RemoteWebDriver HttpHostConnectException

[David Lumpkin]

I'm having an issue using Gradle to run Geb/Spock tests against a local ChromeDriver where parallel test threads intermittently throw the exception below. It doesn't seem to happen when I run the tests with a single thread, but I'm not sure that's the root cause (nor is it an acceptable solution). My best guess is that somehow certain threads are getting disconnected from ChromeDriver and defaulting to RemoteWebDriver. Has anyone else seen symptoms like this?

org.apache.http.conn.HttpHostConnectException: Connect to localhost:39985 [localhost/127.0.0.1] failed: Connection refused

Build info: version: '3.4.0', revision: 'unknown', time: 'unknown'

System info: host: 'MBA-200849.local', ip: '192.168.109.63', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.6', java.version: '1.8.0_51'

Driver info: driver.version: RemoteWebDriver

org.openqa.selenium.WebDriverException: org.apache.http.conn.HttpHostConnectException: Connect to localhost:39985 [localhost/127.0.0.1] failed: Connection refused

Build info: version: '3.4.0', revision: 'unknown', time: 'unknown'

System info: host: 'MBA-200849.local', ip: '192.168.109.63', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.6', java.version: '1.8.0_51'

Driver info: driver.version: RemoteWebDriver

at org.openqa.selenium.remote.service.DriverCommandExecutor.execute(DriverCommandExecutor.java:91)

at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:637)

at org.openqa.selenium.remote.RemoteWebDriver.get(RemoteWebDriver.java:364)

at geb.Browser.go(Browser.groovy:511)

at geb.Page.to(Page.groovy:266)

at geb.Browser.via(Browser.groovy:616)

at geb.Browser.to(Browser.groovy:570)

at geb.Browser.to(Browser.groovy:548)

at geb.Browser.to(Browser.groovy:537)

at geb.spock.GebSpec.methodMissing(GebSpec.groovy:56)

at com.craftsy.specs.ErrorSpec.check invalid url(ErrorSpec.groovy:17)

Caused by: org.apache.http.conn.HttpHostConnectException: Connect to localhost:39985 [localhost/127.0.0.1] failed: Connection refused

at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:159)

at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)

at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)

at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)

at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)

at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)

at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)

at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72)

at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)

at org.openqa.selenium.remote.internal.ApacheHttpClient.fallBackExecute(ApacheHttpClient.java:157)

at org.openqa.selenium.remote.internal.ApacheHttpClient.execute(ApacheHttpClient.java:87)

at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:161)

at org.openqa.selenium.remote.service.DriverCommandExecutor.execute(DriverCommandExecutor.java:82)

... 10 more

Caused by: java.net.ConnectException: Connection refused

at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)

at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)

at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

at java.net.Socket.connect(Socket.java:589)

at org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:75)

at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)

... 23 more

[Marcin Erdmann]

How are you managing your WebDriver instances? Are you using Geb's built-in cache for that? If so, did you switch it to cache an instance per thread when running tests against multiple threads as per http://gebish.org/manual/current/#driver-caching-configuration?

Marcin

P.s. I'd suggest to not run tests in a single test JVM on multiple threads but rather run them single threaded across multiple test JVMs (see https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:maxParallelForks) - things are easier to manage that way if only you can afford the increased resource consumption coming from spinning up multiple JVMs.

--
You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+unsubscribe@googlegroups.com.
To post to this group, send email to geb-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/bfd28923-f8d7-46f7-9a0d-c832fd3053ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.