Corrupted selenium server jar

[gtramontina]

Hi there,

I used webdriver-manager to download the latest version of the selenium server. In my protractor.conf.js I specify seleniumServerJar so that protractor would take care of starting it up and shutting it down. Then, when running the tests, I started getting a timeout when starting the selenium server.
Digging into protractor's code, I found that protractor is only accounting for the happy path when running java -jar .... It turns out that the selenium server jar that was downloaded with webdriver-manager got corrupted somehow (during download, probably) and protractor didn't know about that.

My suggestion here is to also consider this scenario, as I spent an awful lot of time to figure this out.

[juliemr]

What did your errors look like?

[gtramontina]

Nothing besides a timeout, check it out:

------------------------------------
PID: 60145 (capability: firefox #1)
------------------------------------

Starting selenium standalone server...

/Users/me/workspaces/app/node_modules/selenium-webdriver/lib/webdriver/promise.js:1702
      throw error;
            ^
Error: Timed out waiting for the WebDriver server at http://10.27.12.71:55274/wd/hub
    at Error (<anonymous>)
    at onResponse (/Users/me/workspaces/app/node_modules/selenium-webdriver/http/util.js:87:11)
    at /Users/me/workspaces/app/node_modules/selenium-webdriver/http/util.js:42:21
    at /Users/me/workspaces/app/node_modules/selenium-webdriver/lib/webdriver/http/http.js:96:5
    at ClientRequest.<anonymous> (/Users/me/workspaces/app/node_modules/selenium-webdriver/http/index.js:128:7)
    at ClientRequest.EventEmitter.emit (events.js:95:17)
    at Socket.socketErrorListener (http.js:1547:9)
    at Socket.EventEmitter.emit (events.js:95:17)
    at net.js:440:14
    at process._tickCallback (node.js:415:13)
[launcher] Runner Process Exited With Error Code: 8

You can reproduce easily by replacing the selenium server jar with a dummy file:

rm node_modules/protractor/selenium/selenium-server-standalone-2.40.0.jar
touch node_modules/protractor/selenium/selenium-server-standalone-2.40.0.jar

[juliemr]

Thanks for providing more info. I suppose webdriver-manager could do something to check the size of your downloaded files, but I'm not sure how else this could be avoided. Ideas welcome.

[gtramontina]

Besides surfacing these type of errors, I believe validating the checksum (if provided) would work.

[gtramontina]

Ok, issuing a HEAD request to http://selenium-release.storage.googleapis.com/2.40/selenium-server-standalone-2.40.0.jar, for example, it returns the checksum in the ETag header. We could use that to validate the download.

curl -I -s -X HEAD http://selenium-release.storage.googleapis.com/2.40/selenium-server-standalone-2.40.0.jar | awk 'BEGIN {FS=": "}/^ETag/{print $2}' | tr -d \"

And then, we can simply compare the just downloaded file's md5 with the ETag value we got before downloading.

[juliemr]

b67810a is pretty simple (it just checks the response code), but I think it'll cover the problem cases. Please open a new issue if problems persist!

[gtramontina]

Would you mind a complete rewrite of this module? I mean, if I spare some time to do this from scratch, bringing in existing modules like request to do some of this work, would it be interesting?

[gtramontina]

Thanks a lot, btw. :-)

[juliemr]

@gtramontina I wouldn't mind a rewrite - it's a pretty unpolished module. However, keep in mind that the project is trying to keep dependencies to a minimum, so if another module isn't necessary or adds complexity, we really try to avoid it.

[jonniespratley]

Doesn't seem like this is fixed.

[doshprompt]

@jonniespratley yes agreed, this is definitely still broken in edge cases where the network drops after the file has begun downloading or times out if the network is too slow.

@juliemr can you reopen the issue or should I just submit an independent PR?

I like the idea of validating with the HEAD request but maybe we don't need to go all the way and include another dependency, I am not sure if that's possible though.

[deckar01]

This is currently causing my tests to fail sporadically.

...
Updating selenium standalone
downloading https://selenium-release.storage.googleapis.com/2.44/selenium-server-standalone-2.44.0.jar...
Updating chromedriver
downloading https://chromedriver.storage.googleapis.com/2.12/chromedriver_linux64.zip...
chromedriver_2.12.zip downloaded to /home/travis/build/stellar/stellar-client/node_modules/protractor/selenium/chromedriver_2.12.zip
...
Starting selenium standalone server...
/home/travis/build/stellar/stellar-client/node_modules/protractor/node_modules/selenium-webdriver/lib/webdriver/promise.js:1761
      throw error;
            ^
Error: Timed out waiting for the WebDriver server at http://127.0.0.2:58818/wd/hub
    at Error (<anonymous>)
    at onResponse (/home/travis/build/stellar/stellar-client/node_modules/protractor/node_modules/selenium-webdriver/http/util.js:87:11)
    at /home/travis/build/stellar/stellar-client/node_modules/protractor/node_modules/selenium-webdriver/http/util.js:42:21
    at /home/travis/build/stellar/stellar-client/node_modules/protractor/node_modules/selenium-webdriver/lib/webdriver/http/http.js:96:5
    at ClientRequest.<anonymous> (/home/travis/build/stellar/stellar-client/node_modules/protractor/node_modules/selenium-webdriver/http/index.js:145:7)
    at ClientRequest.emit (events.js:95:17)
    at Socket.socketErrorListener (http.js:1551:9)
    at Socket.emit (events.js:95:17)
    at net.js:440:14
    at process._tickCallback (node.js:419:13)

https://travis-ci.org/stellar/stellar-client/builds/41554839#L856