Karma: random DISCONNECTED messages from PhantomJS

[ibawt]

Hi,
Karma: 0.8.6
PhantomJS: 1.9
Node: v0.10.2, v0.10.7

I'm seeing random disconnect messages in single run mode. Is this a known problem? I tried monkey patching the socket.io transports to only do xhr and jsonp but it still happens. Any ideas?

[vojtajina]

I believe there was some issue with Node + socket, it should be fixed in Node 0.10.12, can you try to udpate node ?

[glyphobet]

We are having this too, with these versions:

• PhantomJS 1.8.2
• Karma 0.9.4
• Node 0.10.12

[ibawt]

same issue with the latest node.

[vratojr]

Same problem with:

Phantom 1.9.1
Karma 0.8.7
Node 0.10.15

[calystoramesh]

same problem for me,
windows XP

Node: v0.10.21
Karma v0.10.4
Phantom 1.9.2

[apraditya]

Same here with:

• Phantom 1.9.2
• Karma 0.9.3
• Node 0.10.5 and 0.10.21

[vojtajina]

Can you guys try to debug it a bit to see what's going on in the browser?
https://github.com/ariya/phantomjs/wiki/Troubleshooting

[vojtajina]

It might be related to #558.

[NateRedding]

I keep having this problem too - everything works fine in Chrome, but switching to PhantomJS seems to result in unpredictable behavior. I have tried configuring each of the different transport options individually, but typically get the same behavior.

OS: Mac OS X - 10.9.2 (Mavericks)
Node: 0.10.26 (installed via homebrew)
PhantomJS: 1.9.7
Karma: 0.12.0

Here is the output (the test that fails varies from run to run):

WARN [PhantomJS 1.9.7 (Mac OS X)]: Disconnected (1 times), because no message in 10000 ms.

PhantomJS 1.9.7 (Mac OS X): Executed 108 of 559 DISCONNECTED (30.895 secs / 21.301 secs)

[NateRedding]

I have it configured for debugging... is there any particular information that would help? I don't seem to get much info from the Network or Timeline tabs. I can turn on profiling, but I'm not sure how much that will tell us... actually it seems like the disconnect causes Phantom to shutdown before the profiling information is returned. Do you have any suggestions on good places to put breakpoints maybe?

[readme42]

Same Problem here:

PhantomJS 1.9.7 (Linux): Executed 99 of 304 SUCCESS (0 secs / 0.567 secs)
WARN [PhantomJS 1.9.7 (Linux)]: Disconnected (1 times), because no message in 10000 ms.
PhantomJS 1.9.7 (Linux): Executed 99 of 304 DISCONNECTED (13.154 secs / 0.567 secs)

This problem occurs randomly, sometimes everything is fine, sometime it breaks. But when it breaks, it breaks always at test 99.

Karma 0.12.4
PhantomJS 1.9.7
grunt-karma 0.8.0
Node 0.10.26

[bitwiseman]

I'm getting this on other browsers than phantomJS on karma 0.12.16.

[geekytime]

I'm getting this on other browsers than phantomJS on karma 0.12.16.

I have multiple configurations for multiple browsers that work when I have singleRun: false in my config. As soon as I set singleRun:true, I get this:

DEBUG [karma]: A browser has connected on socket tmAcxXBuoIKtPUKBtY0z
INFO [Firefox 29.0.0 (Mac OS X 10.9)]: Connected on socket tmAcxXBuoIKtPUKBtY0z with id 51306248
DEBUG [launcher]: Firefox (id 51306248) captured in 14.92 secs
WARN [Firefox 29.0.0 (Mac OS X 10.9)]: Disconnected (1 times), because no message in 10000 ms.

DEBUG [karma]: Run complete, exitting.

This is happening in PhantomJS, Chrome, and Firefox.

[sylvain-hamel]

I had a similar problem on my continuous integration server at work. I found out that the machine was so busy that it was in fact timing out for real. I set the timeout to 30 sec and that solved the problem. I'm not saying that this is a final solution for you guys but if you increase the timeout and and it stops failing, we might have more information to investigate.

[geekytime]

I set the timeout to 30 sec and that solved the problem.

The captureTimeout option defaults to 60 seconds, right? And the browsers are getting captured, fine, so I didn't think that one would help.

I dug around the docs looking for other timeout options, but I couldn't find any. Is there maybe another hidden option for a "wait for execution to start" timeout?

[sylvain-hamel]

There are 4 timeouts, from config.js in source code

  this.captureTimeout = 60000;
  this.browserDisconnectTimeout = 2000;
  this.browserDisconnectTolerance = 0;
  this.browserNoActivityTimeout = 10000;

I dont remember which one I changed but browserNoActivityTimeout could be the one. I don't have access to my work PC right now. Let us know if one of the above helps.

[geekytime]

browserNoActivityTimeout could be the one

Yup. That did the trick! I should have thought to check the source. Thanks for your help!

[sylvain-hamel]

Sure!

[bajtos]

browserNoActivityTimeout could be the one

Works for me too :+1:

[readme42]

For me too :+1:

[jhuesos]

It solved the problem for me too.

Can we add this modification to the code? Is there any problem with that? SCRATCH THAT!

I see you can see that option in the karma conf file...

[sabarasaba]

It solved the problem for me as well.

[kvcrawford]

Once our test suite got to a certain size, our build server started consistently failing to complete the tests. Adjusting the timeout settings helped, but didn't resolve the issue—we were still getting failures maybe 30-50% of the time.

Upgrading the server from a 4 GB single core to 16 GB quad-core has solved the problem, for now.

[headbozo]

I had the issue with PhantomJS when running on the build server. When tests were running on local computer everything was fine but browser kept disconnecting when running on build server. I dug to the core of the problem. Our application start page had a component which was trying to reach external site and it could do it on local computer but that was forbidden on build server. That caused some significant delay while loading page and in turn that led to no activity timeout. Karma just disconnected client because of that and it took me some time to figure out what was the reason. I think it may be better when browser is pinging karma so it could track browser activity than just timeout. Or may be combination of both approaches would be even better when it times out if it does not receive next ping in certain time interval.

[jhuesos]

We are getting this issue more often in some machine even with:

browserNoActivityTimeout: 60000

I will try to increase it even more, but there is something wrong here. Any suggestions, ideas? Thanks

[garethhunt]

Ran into this problem on our build servers. The root problem was available RAM. PhantomJS is quite memory hungry and was consuming ~75% of the available 2GB RAM. The 1100 tests would take 1m30s to run and then the build would fail when phantomJS failed to disconnect after 60000ms.

Increasing the build node VM RAM from 2GB to 4GB resulted in the 1100 tests completing in 45s and the browser disconnecting within 5s.

Of course this means we need to profile our code to determine why so much memory is utilized...

[mtscout6]

I've noticed that using pre-processors can cause this to increase as well. Since karma launches the browser then processes all the files. If your preprocessors take a long time to run then I'll bet you see a direct correlation.

[nuweb]

I get the same error.
OSX - 10.9.5
Karma version: 0.12.31
phantomjs version 1.9.8
node --version 0.10.33

->grunt karma
Running "karma:unit" (karma) task
INFO [karma]: Karma v0.12.31 server started at http://localhost:9876/
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.8 (Mac OS X)]: Connected on socket vo0VCply3aIvM70g5H5C with id 93719535
PhantomJS 1.9.8 (Mac OS X): Executed 1 of 9 SUCCESS (0 secs / 0.001 secs)
PhantomJS 1.9.8 (Mac OS X): Executed 1 of 9 DISCONNECTED (12.386 secs / 0.001 secs)
Warning: Task "karma:unit" failed. Use --force to continue.

Aborted due to warnings.

Here's the repo..
https://github.com/nuweb/angularjs-requirejs-jasmine-karma-protractor-seed

[bajtos]

Adding the following lines to my karma config solved the problem for me:

     // If browser does not capture in given timeout [ms], kill it
     captureTimeout: 60000,

+    // to avoid DISCONNECTED messages
+    browserDisconnectTimeout : 10000, // default 2000
+    browserDisconnectTolerance : 1, // default 0
+    browserNoActivityTimeout : 60000, //default 10000

Source: webpack/karma-webpack#8

[sloria]

@bajtos' workaround worked for me.

I am only seeing this error when I run in --single-run mode.

[veeracs]

@bajtos workaround did not work for me. I'm consistently getting DISCONNECTED error.

[myartsev]

@veeracs, I kept getting the same error on a build server with 3.5GB of RAM.
The PhantomJS startup time was consistently around >0.9sec && <=2sec over five builds.

I've increased the _browserNoActivityTimeout_ to 3 seconds as a workaround.

[monitorjbl]

@bajtos workaround did not work directly for me, I had to increase the retry count to an obscenely high 100 to prevent these random disconnects from breaking the build.

[Goffen]

We got the same problem with intermittent test-runs. Once in a while phantomjs wont connect to the websocket in time so the testrunner will timeout and shut down. I think its quite related to the load on the computer running the tests. On everyones developer-machine everything is fine but on the very pressured build-server we get these problems.

[jeffcai]

Yes, I got such problem. As Goffen said, it only occurs on the machine with very high load but on local machine it's fine to run test.

[mik01aj]

The same for me. I also noticed that this happens mostly with --single-run, like @sloria said.

[bensquire]

Same problem here. We run the test in our CI process and this is causing the build to fail. '--single-run' in this case as well.

Interestingly I notice that the first 100 tests run in ~2 seconds, the last 100 (around the 900 mark) take nearly 2 minutes to execute.

@bajtos Settings didn't do anything for us (in fact we already had it set).

[darrinholst]

Seeing this as well on our ci server (m3.medium). I traced it down to never reaching here. I then put a bunch of console.logs in various spots in our code to see if I could pinpoint a problem with our code, but the results were random. I'm suspicious of the culprit being phantomjs, but I can't figure out how to see what it's doing while it's hanging (top shows that phantomjs is doing _something_). This started happening after upgrading node 0.10 to either iojs 2.5 or iojs 3.3.

karma 0.12.37
phantomjs 2.0.1 (debian)
iojs 2.5 or 3.3

As a temporary workaround I'm going with the following config for karma...

browserDisconnectTimeout: 5000,
browserNoActivityTimeout: 5000,
browserDisconnectTolerance: 10,

This will give it 10 times to try and run. I've found that if it's going to run it's going to start in the first couple seconds hence the 5 second no activity timeout to fail faster.

I can reproduce this reliably if anyone has any suggestions for debugging this.

[kublanov]

We also had similar issues in our CI environment.
Karma and PhantomJS did not work properly together, meaning that PhantomJS was able to connect to Karma Server, but did not get any request from it. Also ended up sometimes in:

Disconnected (1 times), because no message in ...

Seems to be related to singleRun mode.

After spending few hours, we've implemented a workaround by using following combination of the two properties:
browserNoActivityTimeout: 15000
and
browserDisconnectTolerance: 5

This way if PhantomJS does not get any messages from Karama Server it tries to reconnect to it, and gets immedeataly served with the messages.

[gillius]

This has been happening to us since the beginning of our project about a year and a half ago, but only on our CI server TeamCity. Now we got a newer, nicer, faster server and I hoped all would be better, with it running the newest node and phantomjs. It's not better -- in fact it's a lot worse. It's definitely presenting like a race condition considering that it's random. We're going to try:

captureTimeout: 2000,
browserDisconnectTimeout: 2000,
browserDisconnectTolerance: 3,
browserNoActivityTimeout: 10000,

And see if that helps.

[gillius]

In our case, the tests either time out or only take about second to run (there are not many Karma tests). On the old server it would timeout maybe once a week (we do about 20 builds a week), now on the faster server with newer nodejs it happened twice yesterday.

[gillius]

It looks like the settings can help:

[09:11:48] Running "karma:unit" (karma) task
[09:11:48] INFO [karma]: Karma v0.12.3 server started at http://localhost:9001/
[09:11:48] INFO [launcher]: Starting browser PhantomJS
[09:11:50] WARN [launcher]: PhantomJS have not captured in 2000 ms, killing.
[09:11:50] INFO [launcher]: Trying to start PhantomJS again (1/2).
[09:11:51] INFO [PhantomJS 1.9.8 (Windows 8)]: Connected on socket ebGv2MP9M-QYib0V4pRp with id 67313362
[09:11:52] ..........................................
[09:11:52] PhantomJS 1.9.8 (Windows 8): Executed 42 of 42 [32m SUCCESS [39m (0.162 secs / 0.374 secs)
[09:11:52] 
[09:11:52] Done, without errors.

[moacir-selinger]

I was having the same problems with the projects where I work. When we have a considerable amount of testing, the problem starts to occur.

As above conversation, I added in my _karma.config.js_ the line browserNoActivityTimeout: 60000 and the problem did not occur anymore.

Thank you for your personal contribution.

[oshalygin]

The above configuration from @gillius solved the issue for me. I think I spent a solid day on this going back and forth. THe worst part for me was that I was chasing around this error:
SetProcessDpiAwareness failed: "COM error 0x80070005 (Unknown error 0x0ffffffff80070005)

Which almost(operative word here), always lead to a karma timeout.

The first few times I saw that the above error and timeout did not ALWAYS happen in unison, I came here.

For the record the above error is on a Windows Server 2012 CI box.

[dignifiedquire]

There is nothing actionable on the karma side of things for this so I'm going to close this.

[nickawatts]

I encountered the disconnect problem this week too. After way too much experimentation with different combinations of versions of Node, Karma, Karma launchers and PhantomJS, I realized it had to be something I did, not the tools. I eventually figured out that my problem was a very poorly written (authored by, of course, me) Jasmine spec that uses Angular's ngMock.$httpBackend object to unit test an Angular service.

I was doing something like this:

it('should fail on GET request with invalid username/password', function() {
  $httpBackend.whenGET(/.*/).respond(500);
  ...
  $httpBackend.expectGET("authenticate");
  $httpBackend.flush();
});

I'm still not 100% sure why, but this caused something to hang indefinitely, which caused Karma to never respond, which eventually led to PhantomJS timing out. Using .* as a regex for possible URIs is a horrible idea that I had forgotten I did "temporarily".

The point is, if you see too have a problem like what is described here, it's likely to be something going wrong in your test suite and not a bug in Karma or PhantomJS.

[odikusar]

I solved this problem by updating the browser
sudo apt-get install chromium-browser
or
sudo apt-get install google-chrome-stable