Meteor loses connection to MongoDB

I’m running multiple copies of an app (different target groups) on meteor.com. They connect with mongoDB.com. Everything runs smoothly up to a certain point. Sometimes they seem to loose the connection to MongoDB. Some of the apps don’t get any traffic since we haven’t released them, but the issue is still there. So it is not a load issue. This is what I find many times in the logfiles:

MongoTimeoutError: Server selection timed out after 10000
2021-10-19 09:58:21+02:00 at Timeout._onTimeout (/app/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb-core/lib/sdam/topology.js:773:16)
2021-10-19 09:58:21+02:00 at listOnTimeout (internal/timers.js:549:17)
2021-10-19 09:58:21+02:00 at processTimers (internal/timers.js:492:7)
2021-10-19 09:58:21+02:00 => awaited here
2021-10-19 09:58:21+02:00 at Function.Promise.await (/app/bundle/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:56:12)
2021-10-19 09:58:21+02:00 at packages/mongo/mongo_driver.js:1037:
2021-10-19 09:58:21+02:00 at /app/bundle/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:
2021-10-19 09:58:21+02:00 => awaited here:
2021-10-19 09:58:21+02:00 at Promise.await (/app/bundle/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:60:12)
2021-10-19 09:58:21+02:00 at SynchronousCursor._nextObject (packages/mongo/mongo_driver.js:1086:38)
2021-10-19 09:58:21+02:00 at SynchronousCursor.forEach (packages/mongo/mongo_driver.js:1100:22)
2021-10-19 09:58:21+02:00 at SynchronousCursor.getRawObjects (packages/mongo/mongo_driver.js:1149:12)
2021-10-19 09:58:21+02:00 at PollingObserveDriver._pollMongo (packages/mongo/polling_observe_driver.js:156:44)
2021-10-19 09:58:21+02:00 at Object.task (packages/mongo/polling_observe_driver.js:93:12)
2021-10-19 09:58:21+02:00 at Meteor._SynchronousQueue.SQp._run (packages/meteor.js:917:16)
2021-10-19 09:58:21+02:00 at packages/meteor.js:894:12 {
2021-10-19 09:58:21+02:00 name: 'MongoTimeoutError',
2021-10-19 09:58:21+02:00 [Symbol(mongoErrorContextSymbol)]: {}

The only way I managed to resolve this is by re-deploying the app. The mongoDB database is still running fine, I don’t have to touch it to resolve this issue. How can I prevent this from happening?

1 Like

do you use these connection parameters?

MONGO_URL: 'mongodb+srv://xxxxx:yyyyyy@chacha.bumbum.mongodb.net/meteor?retryWrites=true&w=majority&connectTimeoutMS=60000&socketTimeoutMS=60000',

The timeout parameters were missing, I have added them. Lets see if that helps. Thanks for your suggestion. It’s still strange though, the logs are full with these messages and the apps won’t load. So increasing the timeout time doesn’t seem like a robust solution to me.

It’s caused by a timeout because the server times out. The best way to fix it is buy your own server and do it all yourself so you don’t have to share and can be sure you have dedicated service. A dedicated 16cpu instance with 16gb ram will be able to run it all no problem at all, plus you own the server and can do whatever you want with it.

1 Like

The app runs very fast and has a low load right now. It’s just that sometimes it starts giving many timeouts until I re-deploy it. Then it runs fast again. It’s just like it can’t connect to Mongo anymore, even though it is still running.

1 Like

What version of Meteor are you running?

Yes that will be because you are sharing so when another App that has nothing to do with you, gets their peak traffic or get’s busy for whatever reason, the server times out and you are effected by it. This is what happens on shared servers. It’s just how it goes.

We updated it a couple of times, it is now running the latest version actually. But that didn’t make a difference.

I see what you are saying, but I still find it hard to believe that a service like meteor.com suffers from it in such a bad way. It’s not a cheap service. It also seems to be all or nothing with the app. Either extremely fast or not working at all.

To be honest though, since the last deployment (with the timeout settings) everything has been running smoothly. Might be a coincidence, so fingers crossed…

1 Like

I agree 100%. In theory it shouldn’t happen.

I tried meteor’s hosting and had really poor performance, timeouts and a lot of variable latency, so can only say it happened to me and the way I fixed it was moving to my own servers and hosting myself. I have also had the same at AWS.