Docker-selenium: Chrome-Node Cycles Between Registered And Unregistered (3.3.0-Americium and Latest Branch)

[tparikka]

Meta -

Image(s):

Docker Version:

OS:

I'm using Selenium 3.3.0 with C# bindings and NUnit for my test framework. I am running into tests failing with:

Test Name: TESTNAME
Test FullName: CLASSNAME(Chrome).TESTNAME
Test Source: C:\source\TestAutomation\Main\TESTFILE.cs : line 151
Test Outcome: Failed
Test Duration: 0:00:00.015

Message: System.InvalidOperationException : Session [6bd6b2c8-8eb6-4283-922a-f848c4f55d2c] was terminated due to PROXY_REREGISTRATION
TearDown : System.InvalidOperationException : Session [6bd6b2c8-8eb6-4283-922a-f848c4f55d2c] was terminated due to PROXY_REREGISTRATION

I am starting the grid using docker-compose up -d and then docker-compose scale chrome=4 with the following docker-compose.yml:

selenium-hub:
image: selenium/hub:3.3.0-americium
ports:
- "4444:4444"

chrome:
image: selenium/node-chrome:3.3.0-americium
links:
- selenium-hub:hub
volumes:
- /dev/shm:/dev/shm

Looking at the logs, it appears that nearly immediately after the chrome-node registers to the hub, it begins a cycle of registering and then de-registering:

Expected Behavior -

chrome-node stays registered to the hub after it is instantiated and registered

Actual Behavior -

chrome-node continually registers and deregisters, causing tests to fail

[ddavison]

i've tried and tried to reproduce this issue, and i cannot reproduce.. my best guess is that you might have some networking conflicts on your end. it looks as if your node either cannot reach your hub, or your hub cannot retain a connection. have you tried the most recent version?

It's building / publishing as I write this message, so will hopefully be available when you read this message.

You can monitor it here: https://travis-ci.org/SeleniumHQ/docker-selenium/builds/216183912

It is building 3.3.1-arsenic. Try once again with that image, and if it persists, we can reopen this issue.

[tparikka]

@ddavison Looking at TravisCI, the build for the new 3.3.1-arsenic branch failed. I'll try it when it builds and is published to the Docker repo (unless there's a way to get it sooner?). I tried pulling selenium/hub:latest and selenium/node-chrome:latest, had the same results there as I did with americium. The issue does not occur in the 3.2.0 release.

What types of networking conflicts might I have? Internally the containers are using 172.17.0.x. I have no adapters listening on an address or subnet that would conflict with anything on that private range up to 172.17.0.0/16 (though I'm assuming the containers are using a /24). Docker Networking is set up to use a subnet address of 10.0.75.0/24, no conflicts there either.

[testphreak]

CI is still failing. Explains why 3.3.1-arsenic is not available to pull. Also, the build status icon still points to Circle CI on the home page under README.md instead of Travis CI.

Can that be updated as well?

Looking forward to the images being published soon.

[cmosher01]

Does it make sense to prevent failing builds from getting into the "latest" docker-hub image?

[testphreak]

@cmosher01, yes it does. You always want your unit and integration tests to pass before you deploy a service for general consumption.

[ddavison]

@tparikka think you'd be able to help out and fix that circle ci thing :D 😺

[sporokh]

Just tested in my own environment:
Selenium 3.2.0 doesn't have this issue and works fine, while new version 3.3.0 cycling node to deregister every couple of seconds. Any fixes to 3.3.0?

[Zechtitus]

Just tried 3.3.1 - issue still present. 3.2.0 works fine as @sporokh mentioned.

[diemol]

I see the issue with the 3.3.0 images, but with the 3.3.1-Cesium images it works for me.

I remember there was an issue with the Selenium 3.3.0 release, one or more status URLs were broken and that was one of the reasons why they needed to release a quick hot-fix. I am assuming that if you check now with the 3.3.1 image it should work as usual.

[tparikka]

The issue also appears to be resolved for me as of 3.3.1-Cesium. @Zechtitus and @sporokh can you please try it with :latest or :3.3.1-Cesium specifically and let us know if it's worked? I'll close this issue if I don't hear back within a few days.

[taraa62]

I have the same problem with version 3.3.1, I also tried 3.2.0, the problem remained.
Initial data:
Os: mac os 10.12.4
Connect node: appium (ios)
Configuration for hub: default

[diemol]

@taraa62,
Which image exactly? What do you mean by Appium? Is there a docker-selenium image for Appium?

[Zechtitus]

@tparikka - just tried :latest and issue still is occurring (selenium/hub, selenium/node-chrome-debug).

The 3.3.1-cesium was working for the same test... so I am unsure if the issue occurs sporadically or is dependent on some timing (The page I was reproducing it against had some 3rd part advertisements which affect the page loading time somewhat in our test environment).

I'm doing a pull on latest again just to check, maybe it was cached from Friday. Will update in a few min here.

Update: Seems to work fine now with latest - ran it thru a few times to make sure. Guess if people are verifying make sure you do the docker pull step (I forgot)

[diemol]

@Zechtitus, that is what I was thinking, better always make sure to have the latest by doing a docker pull again.

Looks like this one can be closed, right?

[tparikka]

@Zechtitus Glad to hear it's working with the latest pull. @taraa62, I suspect you're using the Docker images provided by Appium here, yes? My understanding is that Appium uses WebDriver to automate testing of mobile applications, so what I would suggest is:

1) Make sure to do a fresh pull with docker pull selenium/hub:3.3.1-cesium as @Zechtitus did
2) If you still encounter issues, work with the Appium team at their project's GitHub to determine the source of the issue - it could be that their image is using an older release of Selenium, or something else entirely.

If the root cause is somewhere in our container we can re-open this issue but I suspect it will be somewhere within Appium's image and ecosystem. I will close this issue unless it's determined that changes need to be made on our side.

[Saxson]

Isn't it due to the config? Check the timeout in the config