Occasional PhantomJS start-up issues on Travis

[halfer]

I'm using the phantomjs driver for my browser tests and am having some intermittent problems on Travis (I may switch some of the tests to simple as I don't always need JavaScript, but I'd like to get this stable first).

Occasionally PhantomJS hasn't started when it should have, and so Spiderling crashes out with an error:

Configuration read from /home/travis/build/halfer/awooga-app/phpunit.xml

...........................................................E..... 65 / 71 ( 91%)

......

Time: 43.07 seconds, Memory: 27.75Mb

There was 1 error:

1) Awooga\Testing\Browser\BrowseTest::testBrowse

Openbuildings\Spiderling\Exception_Driver: Curl "url" throws exception couldn't connect to host

/home/travis/build/halfer/awooga-app/vendor/openbuildings/spiderling/src/Openbuildings/Spiderling/Driver/Phantomjs/Connection.php:263

/home/travis/build/halfer/awooga-app/vendor/openbuildings/spiderling/src/Openbuildings/Spiderling/Driver/Phantomjs/Connection.php:209

/home/travis/build/halfer/awooga-app/vendor/openbuildings/spiderling/src/Openbuildings/Spiderling/Driver/Phantomjs.php:273

/home/travis/build/halfer/awooga-app/vendor/openbuildings/spiderling/src/Openbuildings/Spiderling/Page.php:33

/home/travis/build/halfer/awooga-app/vendor/openbuildings/phpunit-spiderling/src/Openbuildings/PHPUnitSpiderling/Testcase/Spiderling.php:222

/home/travis/build/halfer/awooga-app/test/browser/tests/BrowseTest.php:18

/home/travis/build/halfer/awooga-app/test/browser/tests/BrowseTest.php:18

FAILURES!

Tests: 71, Assertions: 204, Errors: 1.

In the example there is one 'E' failure, but Spiderling/PhantomJS has worked fine for another ten or so. And if I restart the build in Travis, it then works fine!

I've added logging code to see if I can see anything about why PhantomJS might fail to start up, thus:

/**
 * Let's set add some logging here, to see why PhantomJS is flaky on Travis
 */
public function driver_phantomjs()
{
    // We can supply a log location here (or omit to use /dev/null)
    $logFile = '/tmp/phantom-awooga.log';
    $connection = new \Openbuildings\Spiderling\Driver_Phantomjs_Connection();
    $connection->start(null, $logFile);

    $driver = new \Openbuildings\Spiderling\Driver_Phantomjs();
    $driver->connection($connection);

    return $driver;
}

However this doesn't capture anything useful. In the same run, it captures normal PhantomJS traffic, e.g.:

$ cat /tmp/phantom-awooga.log

Starting server on port 4818

Recieved command POST /url http://localhost:8090/browse?search=phppot.com

Executing command POST /url http://localhost:8090/browse?search=phppot.com

http://localhost:8090/browse?search=phppot.com success

Recieved command POST /elements .//descendant-or-self::*[@id = 'addressSearch' and (@value = 'phppot.com')]

Executing command POST /elements .//descendant-or-self::*[@id = 'addressSearch' and (@value = 'phppot.com')]

Recieved command POST /elements .//descendant-or-self::h3[contains(string(.), '11 results')]

Executing command POST /elements .//descendant-or-self::h3[contains(string(.), '11 results')]

Recieved command POST /elements .//descendant-or-self::*[@id = 'paginator']

Executing command POST /elements .//descendant-or-self::*[@id = 'paginator']

Recieved command DELETE /cookies

Executing command DELETE /cookies 

    ....

I might try adding a delay in setUp() in case the PhantomJS binary is still making connections. Also, I am relying on the copy provided in the default Travis build, but locally I use the one from jonnyw/php-phantomjs. I might give that a go, in case it is a later version. It never fails on my local machine (making this much harder to debug!).

I don't know if this is a support issue or a bug - if it is the former I'll happily move it to Stack Overflow. However I wonder if it is rather too niche to get much attention there! (Would be nice to see more eyeballs on this project - I've found Selenium slow and flaky in the past, so it is nice to see alternatives popping up).

[hkdobrev]

We are seeing the same problem from time to time. But I would say it is quite rare.

On Travis CI we use the already provided PhantomJS and this error is more common.

Locally we download the official PhantomJS binary from here: https://bitbucket.org/ariya/phantomjs/downloads It is quite rare to reproduce this locally.

In any case we'd love to have this fixed, but we haven't put much effort into this.

[halfer]

Thanks for that. I have a few things to try, will let you know if I have any luck.

The first thing is that I'm using PHP built-in web server, and starting it via pcntl_fork(). If this fails to start, is it possible that PhantomJS won't reply? I will try fetching a trivial request via file_get_contents() in my setUp() - if the Phantom error persists it will show that it's a Phantom error, and not one relating to the web server.

[hkdobrev]

FWIW we are running Apache on Linux. And also file_get_contents() is not doing the same thing as curl.

Also try setting the Google DNS servers in your /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

or set them up in the respective place for your OS.

[halfer]

And also file_get_contents() is not doing the same thing as curl.

In my case it would be doing the same thing -- I'd be using it to fetch a trivial test link over HTTP.

Also try setting the Google DNS servers

I would be surprised if this is where Travis build unreliability comes from - it will only just have resolved the domains of dependencies (admittedly all on github.com). In any case, it's localhost that it would have problems resolving (Spiderling to PhantomJS, PhantomJS to web server). Maybe I should try 127.0.0.1 instead :-).

(Btw, if you have any thoughts on how to capture PhantomJS start-up messages, I'll try that. My attempt above did not yield anything useful).

[halfer]

This has been very reliable for the past few weeks, so I wonder whether a new version of PhantomJS is responsible. I'll revisit in a month, and if I don't get any more failures I'll put it down to a fixed bug and close.

[hkdobrev]

@halfer Hi there! Have you had a chance of confirming this is now working as expected? We didn't have many issues lately.

[halfer]

I've not touched this for a few months. I think it did settle down, but I don't recall - I'll give it a try in due course, and will let you know.

[halfer]

I've run a few more tests, and I think this has settled down. I don't know if it is due to a new version of PhantomJS or extra wait code I added in back in December/January.

I'll close for now, it can always be reopened if the issue resurfaces. Thanks for chasing up!