Meteor - Connection Timeout. No heartbeat received

Question

I get the following error:

Connection timeout. No heartbeat received.

When accessing my meteor app (http://127.0.0.1:3000). The application has been moved over to a new pc with the same code base - and the server runs fine with no errors, and I can access the mongodb. What would cause the above error?

The problem seems to occur when the collection is larger. however I have it running on another computer which loads the collections instantaneously. The connection to to sock takes over a minute and grows in size, before finally failing:

enter image description here

Have you tried to call the url which is shown in the "Initiator" field by your browser? What does it shows? Also you can click on the row which is red and post a picture of the shown up content there. — Michael, Jul 19 '13 at 11:22
@Michael do you mean Response? There is no response for the failed network call. Also which Initiator field? — rickyduck, Jul 19 '13 at 12:03
The initiator field in the dev tools in your screenshot... There is always a response, in this case it is a response of failure. But which one, what is the exact error message the server is showing? — Michael, Jul 19 '13 at 12:33
I have attached the response to the document (the request gets cancelled by the browser as visible in the initial attachment). The sock.js file exists, the line in question is just an xhr request: ` that.xhr.send(payload);` — rickyduck, Jul 19 '13 at 12:46
Okay, the status code of the XHR frame is 500 or? Have you tried "meteor reset" in your meteor dir? How was the transaction to the server done? Did you just copy and paste everything in the meteor dir and tried to start meteor? I would try to delete the .meteor/.local/ dir entire. Maybe that helps in the first place? — Michael, Jul 19 '13 at 13:30
The status is `(cancelled)`, and yea I did the `meteor reset` and it worked for a while, then suddenly stopped working after data was added — rickyduck, Jul 19 '13 at 14:05
@Michael however this isn't a code issue from what I can tell. The PC it sits on now is the same one it worked on previously, just upgraded to Windows 7. — rickyduck, Jul 19 '13 at 14:10
Does your other computer use a browser/type of connection which websockets is used instead of xhr? — Tarang, Jul 22 '13 at 12:25
when you say large how many records and what size is each record? finally are you still using the autopublish package? — booyaa, Jul 24 '13 at 08:09
@booyaa it's not ridiculously large, only 200 records in the JobsCollection - and the rows aren't large, just text. There's also 20 employee rows with base64 encoded images saved in the database, but only 20kb images. But when the collections are empty or some data, it runs fine. And yes, I am using autopublish. — rickyduck, Jul 24 '13 at 08:18
yeah fair point, i did some quick calculations, potentially when the app starts up you're trying to sync clients up with at least 0.5mb (20 * 35mb for base64 encoded images). on a local nework and i wouldn't expect that to be a problem. don't suppose there's any chance we can see some of the code? this problem seems very localised at the moment. — booyaa, Jul 24 '13 at 08:31
@booyaa I could post the whole project (as unfortunately I cannot trace the issue) but even if I did this is localized to one OS on one computer (it worked on the same computer in XP, and works on my computer on a different network). I could upload it though if necessary? — rickyduck, Jul 24 '13 at 08:49
@rickyduck yeah if you don't mind sticking it on github or zipping it up. would also be handy if you can script up the data population into server startup code i.e. Meteor.startup(function () { if (Players.find().count() === 0) { insert data into db } — booyaa, Jul 24 '13 at 15:05
@booyaa If I zip it up with the database, would that be ok? Also there is an MSSQL poll in the server - I will have to take out the details of connection for security reasons if that is ok? — rickyduck, Jul 24 '13 at 15:20
ignore the chat request, my work blocks webchat. sorry. yeah exclude the MSSQL stuff — booyaa, Jul 24 '13 at 15:40
just to eliminate websockets from the troubleshooting process, can you try disabling them? you'll need 0.6.4. details can be found here: http://stackoverflow.com/a/17015489/105282 — booyaa, Jul 24 '13 at 15:43
@booyaa just saw your message RE chat, my bad! Booya, here you go: http://files.newedge.co.uk/pytec-kpi-dashboard-app.rar - the username / password is : newedge/newedge The setup is Meteor Preview 0.5.9 on windows. I also have some serious garbage collection issues outside of the scope of the question. — rickyduck, Jul 25 '13 at 08:03
@booyaa I ran the app on 0.6.4 (and replaced all meteor.__bootstrap__.require with Npm.require. I now get an "Exited with code 1" error — rickyduck, Jul 25 '13 at 08:04
Probably mine is a stupid idea but...are you sure about the port in use? I had a bad experience with it: I was working with node on port 5000 and the response was slow, sometimes it didn't arrive at all. I thought it was a problem in the code. When I change it to 4000, only for a lucky case, I saw that all started to go fast and straight. — Max Markson, Jul 26 '13 at 07:22
@MaxMarkson I tried that, unfortunately to no avail. You're right about it being slow though - 20mb of stream takes 1min over LAN.... — rickyduck, Jul 26 '13 at 08:29

score 3 · Answer 1 · answered Dec 07 '14 at 15:54

Meteor's DDP implements Sockjs's Heartbeats used for long-polling. This is probably due to DDP Heartbeat's timeout default of 15s. If you access a large amount of data and it takes a lot of time, in your case, 1 minute, DDP will time out after being blocked long enough by the operation to prevent connections being closed by proxies (which can be worse), and then try to reconnect again. This can go on forever and you may never get the process completed.

You can try hypothetically disconnecting and reconnecting in short amount of time before DDP closes the connection, and divide the database access into shorter continuous processes which you can pick up on each iteration and see if the problem persists:

// while cursorCount <= data {
  Meteor.onConnection(dbOp);
  Meteor.setTimeout(this.disconnect, 1500); // Adjust timeout here
  Meteor.reconnect();
  cursorCount++;
}

func dbOp(cursorCount) {
  // database operation here
  // pick up the operation at cursorCount where last .disconnect() left off
}

However, when disconnected all live-updating will stop as well, but explicitly reconnecting might make up for smaller blocking.

See a discussion on this issue on Google groupand Meteor Hackpad

Meteor - Connection Timeout. No heartbeat received

1 Answers1