Methods "hanging" not returning

bartoftutormundi · January 13, 2021, 11:59am

Hi Andre, I haven’t had this but a friend of mine once described a similar issue to me, he sent me these links below.

I believe in the end he never found the root cause but fixed (or rather, avoided) it by using Meteor.apply instead of Meteor.call

github.com/meteor/meteor

Method Callbacks not being called intermittently

opened 07:36PM - 04 Oct 16 UTC

closed 06:28PM - 19 Oct 17 UTC

ppotoplyak

In the following the client calls server method `recordPing(counter)` every 3 se…cs, with `counter` being incremented by one in the method callback. Client: ``` var pingCount = 0; function heartbeat() { console.log('->recordPing pingCount: ' + pingCount); Meteor.call('recordPing', pingCount, function(err) { if(!angular.isUndefined(err)) alert(err); console.log('<-recordPing pingCount: ' + pingCount); pingCount = pingCount + 1; }); heartbeatTimeout = setTimeout(heartbeat, 3000); } heartbeat(); ``` Server: ``` Meteor.methods({ recordPing: function(pingCounter) { console.log('->recordPing pingCounter : ' + pingCounter + (this.connection != null ? ', called from client' : '')); } }); ``` On Safari/iPhone5 I am intermittently seeing multiple `recordPing` invocations with the _same_ counter value. This could only happen if the method return callback was being delayed. Here is the server log showing a period where the counter is not incremented: ![serverlog](https://cloud.githubusercontent.com/assets/4952152/19088044/09b51930-8a3a-11e6-80d7-752754b993fe.png) The client console confirms that the callback was delayed for 80+ seconds. The client made a call to `pingCounter(111)` at 13:07:25 and executed a callback at 13:08:46. ![clientdelay](https://cloud.githubusercontent.com/assets/4952152/19088819/8cd061b4-8a3d-11e6-915a-33016b78531b.png) Setup info: ``` ppotoplyak@bigscreen:/pit/PixelUprise2$ meteor --version Meteor 1.4.1.1 ppotoplyak@bigscreen:/pit/PixelUprise2$ meteor list angular-with-blaze 1.3.11 Everything you need to use both AngularJS and Blaze templates in your Meteor app angular:angular-cookies 1.5.3_1 AngularJS (official) release. For full solution: http://angular-meteor.com/ angular:angular-sanitize 1.5.3_1 AngularJS (official) release. For full solution: http://angular-meteor.com/ angularui:angular-ui-bootstrap 0.13.0 Native AngularJS (Angular) directives for Bootstrap. angularui:angular-ui-router 0.2.15 angular-ui-router (official): Flexible routing with nested views in AngularJS chrismbeckett:toastr 2.1.2_1 Gnome / Growl type non-blocking notifications cordova:cordova-google-play-services 25.0.0 cordova:cordova-plugin-device 1.1.1 cordova:cordova-plugin-underdevelopment file://.cordova-sv-plugin/ cordova:cordova-plugin-vibration 2.1.1 es5-shim 4.6.14_1 Shims and polyfills to improve ECMAScript 5 support fourseven:scss 3.10.0 Style with attitude. Sass and SCSS support for Meteor.js. http 1.2.9_1 Make HTTP calls to remote servers jquery 1.11.9 Manipulate the DOM using CSS selectors materialize:materialize 0.97.6* Materialize (official): A modern responsive front-end framework based on Material Design meteor-base 1.0.4 Packages that every Meteor app needs mobile-experience 1.0.4 Packages for a great mobile user experience mongo 1.1.12_1 Adaptor for using MongoDB and Minimongo over DDP mrt:modernizr-meteor 2.6.2 Modernizr repackaged for Meteor natestrauser:animate-css 3.5.1 Animate.css packaged for meteor session 1.1.6 Session variable shell-server 0.2.1 Server-side component of the `meteor shell` command. standard-minifier-css 1.2.1 Standard css minifier used with Meteor apps by default. standard-minifier-js 1.2.0_1 Standard javascript minifiers used with Meteor apps by default. stevermeister:angular-flipclock 0.1.1_4 AngularJS wrapper for FlipClock.js tracker 1.1.0 Dependency tracker to allow reactive callbacks twbs:bootstrap 3.3.6 The most popular front-end framework for developing responsive, mobile first projects on the web. ``` I tried [SO](http://stackoverflow.com/questions/39709875/how-to-root-cause-observechanges-latency-spikes) & [Meteor Forums](https://forums.meteor.com/t/does-meteor-have-a-make-check-or-some-other-long-running-tests/29920) while reducing the issue.

github.com/meteor/meteor

Oplog tailing stalls (usually during MongoDB failover) (maybe primarily with Compose Classic)

opened 09:18PM - 13 Apr 17 UTC

closed 11:29PM - 11 Oct 17 UTC

veered

confirmed Project:Mongo Driver Type:Bug Severity:production Impact:most

Using the `replicaSet=...` option in `MONGO_URL` or `MONGO_OPLOG_URL` causes aut…o-reconnects to be disabled on that connection. Since including this parameter is the officially recommended approach, most people using Meteor in prod don't have auto-reconnecting DB connections. I am using Meteor 1.4.3.2, but I think this bug has pretty much always existed. The bug is very easy to reproduce. Locally set `MONGO_URL` to a mongo url that includes `replicaSet=...`. Open up the meteor shell and do a find on a collection; the query should successfully complete. Now reset the network connection on your computer. Try the query again; the query should hang and eventually fail. Now try this same series of steps after removing the `replicaSet` parameter from `MONGO_URL`; notice that the query won't fail. The steps for replicating the problem for `MONGO_OPLOG_URL` is exactly the same. Note: If removing the `replicaSet` parameter crashes your server, then make sure there is only a single host referenced in `MONGO_URL` and that this host is the primary. The main thing going on here is that by passing in the `replSet` parameter the Mongo driver uses the `replset` connection type rather than the `server` connection type. As you can see [here](https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/replset.js#L135) `replset` connections ignore the auto-reconnect property, but `server` connection types [do not](https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/server.js#L129). You can view info about the `MONGO_URL` connection by typing `Meteor.users._driver.mongo.db.serverConfig` into the meteor shell, and info about `MONGO_OPLOG_URL` by typing `Meteor.users._driver.mongo._oplogHandle._oplogTailConnection.db.serverConfig` into the meteor shell. This may be due to a relatively recent change in the mongo driver that happened on June 14th, 2016. [Here is the commit](https://github.com/mongodb/node-mongodb-native/commit/412b50d53dc8e958d3b726fc7f66fe0447b9da66#diff-3995a38a37cf6b7ad44d4c8e63893046R131). But it is also possible that auto-reconnect was never supported for `replset` connections, and that commit is just refactoring the code to reflect that fact. Hard to tell exactly. In any case, it isn't supported anymore. Seems like this problem is related to a bunch of issues people have been having, #5773 being the most popular. Not really sure the best way to fix this. For now I've just dropped the `replicaSet` parameter and made sure that each connection URL only references the primary host, not the secondary. What is the purpose of passing in info about the secondary node (which is the only thing that is forcing us to use the `replicaSet` parameter)? It doesn't really seem to be used for anything except for failover support, and Meteor can't handle failover. I guess if you keep both hosts in the connection URL, Meteor will connect to the new primary upon restart. The only solutions I can think of are: (1) Stop passing in the `replicaSet` parameter (2) Patch the mongo driver so that `replset` connections support auto-reconnects. (3) Handle reconnects at the Meteor level Anyways, this is a pretty important bug. We had some serious outages over the past week because Compose reset all db connections a few times while debugging something unrelated on their end.