node-red-nodes

node-red-nodes copied to clipboard

Hello

Node-Red engine is configured to collect data from a cloud MongoDB and it works usually but sometime it stops with error messages MongoError: Topology was destroyed

I googled much and it seems to be a problem with keeping the connection to the MongpDB server up and running. I mean it looks like if something wrong happens to the existing connection then the driver doesn't even try to re-establish a new one.

10 May 13:09:01 - [info] Node-RED version: v0.17.5 10 May 13:09:01 - [info] Node.js version: v8.15.1 10 May 13:09:01 - [info] Linux 4.14.98-v7+ arm LE => Raspberry PI $ npm --version 6.4.1 ~/.node-red $ npm list | grep mongo ├─┬ [email protected] │ └─┬ [email protected] │ ├─┬ [email protected]

I expect that the implementation of the connection pooling (or something similar used) to keep the connection alive and reliable

from the cloud host:

$ mongo --version MongoDB shell version: 3.2.17

I figured out this week that by adding the useUnifiedTopology=true option in the connect options, that are added to the connection string, solves the problem. It isn't clearly explained in the MongoDB NodeJS client documentation, but this was a breaking change, that should be the only option in the upcoming version 4 release, and would have been the default value in a minor version, but still wasn't enabled in 3.6 (the one node-red-node-mongodb uses now). It should normally be added in the mongoclient constructor, but adding it as a connection string option handles it well.

The unifiedTopology changes how connection, discovery and error handing works, and I find that is really more robust. For me, recovery is flawless for now. https://mongodb.github.io/node-mongodb-native/3.6/reference/unified-topology/

Make sure to use an updated version of node-red-node-mongodb, of at least 0.1.0 (September 14, 2020), when mongodb client's version 3.6.1 was bumped from version 2.2.34.

To reproduce the issue, I had to have some messages waiting to be sent (not completed, I used an MQTT input with a 5 sec delay node to accumulate 10 messages), and to break the internet connection for at least 30 secs (if the driver's default number of retries was set to 30 and a delay of 1000 ms between was used). After that, the client stopped retrying to connect, and when network is back online, and new messages wants to be written, then the client wouldn't try to connect again, and the MongoError: Topology was destroyed error would be written for each message in the console.

Hi - apologies re the other PR. It's just not a node we use so it got completely forgotten about. If you do want to offer up a PR to get it back up to date (or even just to keep it functional) it would be much appreciated. Many thanks

Here I gave the fix to the OP's issue, by changing just the usage of the node, that doesn't really require a change in the code, so I'm not sure what a PR could do to help. I hope that we could get a feedback of the issue even after 2 years, but it should be enough to close the issue.

ah ok - if' its"just" a configuration issue/option then yes - but even docs/info updates are useful :-)