mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
d50b83cc47
* When awaiting Mongo, wait until the heartbeat has pulsed after election. > Prologue: A heartbeat is used amongst members of a MongoDB replica set to poll the status of said members. When we are initiating a new replicaset for the test Mongo server, the replicaset is not fully prepared to accept writes until the voting members have negotiated and propagated their decision about who is the "primary" to all members involved. This seems to be delayed by almost _exactly_ the default heartbeat interval, which is 2000ms. The heartbeat interval is marked as an "internal only" property in Mongo so I was hesitant to lower it. It's also a new property in Mongo 3.2 which might explain why this cropped up a while ago. I believe this heartbeat delay is the only explanation for why the `rs.status()` (i.e. `replSetGetStatus`) believes it is ready before the `mongod` has actually printed "transition to primary complete" to the log. Fixes meteor/meteor#9026. * Replace addl. variable occurrence with the new `firstMemberState` var.
Runners
The Meteor tool process would run multiple big "parts" that should be managed: started, stopped, restarted, monitored for crashes, etc.
The interface that Meteor tool uses is called a "runner".
Some of the runners run sub-processes. The main runner is called run-all, it
has sub-runners such as run-app, run-mongo and run-proxy. Other runners
are used for different CLI commands.
Run Log
The output of the runners (compilation errors, state change, etc), should be reported through the Run Log. Run Log is also something that users see in their browsers, when their app breaks.