1

I'm using Ruby 2.1.0, watir-webdriver, rspec, taza, and PhantomJS 1.9.8. The OS is Linux tester 3.2.0-4-686-pae #1 SMP Debian 3.2.65-1+deb7u1 i686 GNU/Linux.

I run PhantomJS via Watir::Browser.new and supply the following command line parameters: --ignore-ssl-errors=true --ssl-protocol=any --debug=true --cookies-file=/tmp/cookies.txt.

There's a single spec file that fails intermittently (I'd say, likely to fail than pass) at the very beginning: Connection refused - connect(2) for "127.0.0.1" port 8910. In the meantime, netstat -tulpan shows this:

...
tcp        0      0 127.0.0.1:43695         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43723         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43743         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43677         127.0.0.1:8910          TIME_WAIT   -
tcp        0      0 127.0.0.1:43740         127.0.0.1:8910          TIME_WAIT   -
...

Around 90 ports in total. They remain open after rspec has quit. I'm puzzled of the intermittent nature of this failure. Have anyone else encountered the same problem? Any advice, recommendation, link etc. are much appreciated. Thank you.

UPD: I took a closer look and discovered that at some point in time PhantomJS starts dropping connections that income from webdriver: -> [SYN], <- [RST, ACK]. The process remains in memory, but since PhantomJS doesn't keep any error log, I absolutely have no idea what's the cause.

Andrey Esperanza
  • 625
  • 1
  • 6
  • 11
  • yeah this is really seeming like some kind of problem with PhantomJS. Strange that you have only the one spec file that seems to have an issue, Somewhat makes you wonder if something different is happening on the webpage, or in the client side JS code that is causing an issue for Phantom JS. – Chuck van der Linden Feb 14 '15 at 10:26

1 Answers1

0

I don't know if this will solve your problem, but it might explain what you are seeing with netstat. Note that the state shown is TIME_WAIT. reviewing documentation on netstat shows that this is a common state to be displayed for a time after a port is closed

TIME_WAIT Client enters this state after active close

NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). MSL is specified to be 2 minutes. So, a socket could be in a TIME_WAIT state for as long as 4 minutes. Some systems implement different values (less than 2 minutes) for the MSL.

note that comes from this MS support page, so the length of your MSL might differ than 2 minutes as you are on Debian Linux, but the rest is based on the protocol spec, so is going to apply to any OS that implements that spec correctly

How many times does your code open and close the 'browser' object? maybe that has something to do with this? could you be running it out of connections? with a real browser we tend to open the browser at the start of the test run and only close it at the very end, mostly to save on the startup/shutdown time of the browser itself. if you are not doing that for your tests, you might want to experiment and see if it solves your problem.

Community
  • 1
  • 1
Chuck van der Linden
  • 6,660
  • 2
  • 28
  • 43
  • Thanks for your answer. That's the thing – I start browser only once and the large number of opened ports may be the core issue (if there's some limit exists). This test is no different from my prospective from others, but they pass, while this one doesn't. – Andrey Esperanza Feb 10 '15 at 03:48
  • well the connection between webdriver and phantomjs is handled by webdriver. (watir just calls the webdriver api and passes the appropriate parameters) so I'll edit and add some webdriver tags for you, maybe someone more expert at that level can help. – Chuck van der Linden Feb 10 '15 at 17:46