mongodb connection timed out error

Question

I have used mongodb database and node.js v12.0.10 for connecting and updating mongodb collection. connection code is the following:

 async.parallel({
        RE5: function (cb) {
            MongoClient.connect(config.riskEngineDB, function (err, r5DB) {
                cb(err, r5DB);
            })
        },
        MDB: function (cb) {
            MongoClient.connect(config.monitoringDB, function (err, mDB) {
                cb(err, mDB);
            })
        }
    },
    function (err, DBs) {
        assert.equal(null, err);
        console.log("Connected correctly to Dbs");
        // ..doing updates..

 })

after some time running, script printed the following error:

  { [MongoError: connection 39 to 127.0.0.1:27017 timed out]
  name: 'MongoError',
  message: 'connection 39 to 127.0.0.1:27017 timed out' }

For your information, I used different options of connections of mongodb but it didn't make sense.

Answer 1

I wanted to provide this answer as it came up in a mongodb exam question for the free online mongodb university. It's thorough and provides documentation.

I have figured it out and will clean up some confusion mainly caused by a lack of explanation in the lessons. I am not being critical but further explanation is required to properly answer this question.

First, when connecting to mongodb through an application you will be using a driver. This driver has barriors it must pass through in order to do anything with the mongodb server. When you understand this barrior concept you will then understand this question.

Every connection that is ultimately made a list of things have to occur in order to pass throuh the barriers and ultimately conduct a write or read operaton.

Visually you can think of it like this:

IO / write request occurs ==> || 1st barrier --> (server selection - (err -> serverSelectionTimeoutMS ) ) ==> || 2nd barrier --> connection to server - (err -> 'connectionTimeoutMS') ==> || 3rd barrier --> socket connection - (err -> 'socketTimeoutMS') ==****Write Concern Options Barriers**==> || 4th barrier --> 'write concern specification { w: <value>, j: <boolean>, wtimeout: <number> }' ==> || 5th barrier --> a successful write / read operation

*****Note**: Anywhere along this pipeline a falure occurs based on your logic a successful write / read operation may not occur.

We can think of barriers 1 - 3 as network barriers of connectivity. If the network is down or having issues these are the problems one would notice through timeouts and exception handling of those timeouts. What one has to understand is that you can't perform a write operation with write concerns if you can't connect to the server in the first place. The lesson could have illustrated these points.

The first set of barriers to a write or read operation are to have an established connection to the server... This is illustrated above by barries 1 - 3.

Then, after you have a server connection via a cluster and or replica set of clusters then you can define write concerns.

After we have an established connection a write may not happen for reasons other than network connectivity. These can be collisions of data or an extreme allotment of writes due to DDOS or hacking or in general not enough server space for the data be written to the server. Point is, something else can cause a reaction to the write concern and hence the control through options to handle write concern errors.

I hope this helps because it made me understand the question and the right answer accordingly. Mostly, we weren't really taugh this so I hope this helps others learn and understand this feedback loop.

Here are some articles I read to help me get to this answer / conclusion. If someone has a better or improvement on my explanation please feel free to provide feedback.

https://scalegrid.io/blog/understanding-mongodb-client-timeout-options/

https://scalegrid.io/blog/mongodb-write-concern-3-must-know-caveats/

https://docs.mongodb.com/manual/reference/write-concern/

https://www.mongodb.com/blog/post/server-selection-next-generation-mongodb-drivers