Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mongoose not reconnecting when MongoDB driver does #6140

Closed
maloguertin opened this issue Feb 15, 2018 · 29 comments
Closed

Mongoose not reconnecting when MongoDB driver does #6140

maloguertin opened this issue Feb 15, 2018 · 29 comments
Labels
can't reproduce Mongoose devs have been unable to reproduce this issue. Close after 14 days of inactivity.

Comments

@maloguertin
Copy link

maloguertin commented Feb 15, 2018

Do you want to request a feature or report a bug?
bug

What is the current behavior?
When connected to a Mongos container that is restarted Mongoose never reconnects.
I make sure to pass these options:

options = {
    reconnectTries: Number.MAX_VALUE,
    reconnectInterval: 500,
    loggerLevel: 'info'
 }
conn = mongoose.createConnection(config.databaseURL + tenant, options)

However the logs show me that the driver does reconnect:

[INFO-Server:9169] 1518709793526 server 52.91.88.183:27017 fired event close out with message {"name":"MongoNetworkError","message":"connection 2 to 52.91.88.183:27017 closed"} { type: 'info',
  message: 'server 52.91.88.183:27017 fired event close out with message {"name":"MongoNetworkError","message":"connection 2 to 52.91.88.183:27017 closed"}',
  className: 'Server',
  pid: 9169,
  date: 1518709793526 }
[INFO-Server:9169] 1518709794151 server 52.91.88.183:27017 fired event reconnect out with message [object Object] { type: 'info',
  message: 'server 52.91.88.183:27017 fired event reconnect out with message [object Object]',
  className: 'Server',
  pid: 9169,
  date: 1518709794151 }
disconnected
[INFO-Server:9169] 1518709798173 server 52.91.88.183:27017 fired event connect out with message [object Object] { type: 'info',
  message: 'server 52.91.88.183:27017 fired event connect out with message [object Object]',
  className: 'Server',
  pid: 9169,
  date: 1518709798173 }
[INFO-Server:9169] 1518709798206 server 52.91.88.183:27017 connected with ismaster [{"ismaster":true,"msg":"isdbgrid","maxBsonObjectSize":16777216,"maxMessageSizeBytes":48000000,"maxWriteBatchSize":1000,"localTime":"2018-02-15T15:50:55.671Z","maxWireVersion":5,"minWireVersion":0,"ok":1}] { type: 'info',
  message: 'server 52.91.88.183:27017 connected with ismaster [{"ismaster":true,"msg":"isdbgrid","maxBsonObjectSize":16777216,"maxMessageSizeBytes":48000000,"maxWriteBatchSize":1000,"localTime":"2018-02-15T15:50:55.671Z","maxWireVersion":5,"minWireVersion":0,"ok":1}]',
  className: 'Server',
  pid: 9169,
  date: 1518709798206 }

If the current behavior is a bug, please provide the steps to reproduce.

1 Run a nodeJS app that connects to a Mongos on a Docker container
2 Restart your container
What is the expected behavior?
Mongoose should be reconnecting when the container comes back online.

Please mention your node.js, mongoose and MongoDB version.
nodeJS: 8.9.4 and 9.2.0
mongoose: 5.0.5
mongodb: 3.4.10

EDIT:
So I'm using useDb() to connect to other tenant's databases and I just noticed that after the Mongos restart all the calls made to the parent connection db on which I used useDb() works but the calls made on the children connections don't resolve.

Also the readyState is never set to 1 on the parent connection even if the connection is properly reconnected.

@maloguertin
Copy link
Author

I did some digging around in the drivers code and this is what I found:

mongodb-core/lib/topologies/mongos.js

Mongos.prototype.isConnected = function() {
  return this.connectedProxies.length > 0;
}

reconnectProxies(self, self.disconnectedProxies, function() {
        if (self.state === DESTROYED || self.state === UNREFERENCED) return;

        // Are we connected ? emit connect event
        if (self.state === CONNECTING && options.firstConnect) {
          self.emit('connect', self);
          self.emit('fullsetup', self);
          self.emit('all', self);
        } else if (self.isConnected()) {
          self.emit('reconnect', self);
        } else if (!self.isConnected() && self.listeners('close').length > 0) {
          self.emit('close', self);
        }

        // Perform topology monitor
        topologyMonitor(self);
      });
    }

After a disconnect the self.isConnected() check never evaluates to true, therefore the reconnect event is never fired.

@vkarpov15 vkarpov15 added this to the 5.0.8 milestone Feb 15, 2018
@vkarpov15 vkarpov15 added the needs repro script Maybe a bug, but no repro script. The issue reporter should create a script that demos the issue label Feb 15, 2018
@vkarpov15
Copy link
Collaborator

@maloguertin does this happen even if you don't use useDb(), or is useDb() necessary to reproduce this?

@maloguertin
Copy link
Author

maloguertin commented Feb 16, 2018

With this simple script:

import mongoose from 'mongoose'

const dburl = 'mongodb://yourmongosurl:27017/'

mongoose.connect(dburl, {
  loggerLevel: 'info',
  reconnectTries: Number.MAX_VALUE,
  reconnectInterval: 1000
})

mongoose.connection.on('reconnected', () => console.log('dbevent: reconnected'))


setInterval(() => {
  console.log('READYSTATE', mongoose.connection.readyState)
  try {
    mongoose.connection.db
      .admin()
      .ping()
      .then(res => {
        return console.log('ping result:', res)
      })
      .catch(e => console.log(e.message))
  } catch (e) {
    console.log(e.message)
  }
}, 10000)

the results are:

reconnected event never fires.
readyState is never set back to 1.
ping starts working again even if readyState is still 0.

I posted an issue to mongodb-core:
mongodb-core/issues/278

The driver never fires the reconnect event.

Therefore I don't expect this to be a bug on your side, I haven't dug around too much but I'm guessing mongoose relies on the mongodb driver reconnect event to:

  1. fire it's own reconnected event
  2. change readyState back to 1
  3. reconnect connections made with useDb

I experimented a bit and when I changed the check for
self.isConnected()
to
self.state === CONNECTED
in mongodb-core/lib/topologies/mongos.js all the events seemed to happen correctly and the connections from useDb started working again. BUT it seems like this check is too loose because if fired reconnect even when a reconnect did not happen.

@sobafuchs
Copy link
Contributor

I'm going to mark this is as an underlying library issue for now, please report back on how the driver issue is resolved

@sobafuchs sobafuchs added the underlying library issue This issue is a bug with an underlying library, like the MongoDB driver or mongodb-core label Feb 28, 2018
@vkarpov15 vkarpov15 modified the milestones: 5.0.8, 5.0.9 Mar 1, 2018
@simllll
Copy link
Contributor

simllll commented Mar 2, 2018

Is there any workaround we can use in the meantime? I'm experiencing this a lot lately. Connection state stays at "connecting" (2). Restarting or starting a second instance "solves" the issue immediately.

EDIT:
my current "workaround" is to set up a watchdog that handles this case:

function __checkConnection() {
    mongoose.connections.forEach((c, i) => {
        if (c.readyState === 2 && lastState[i] !== 2) { // hangs in "connecting" state
            lastState[i] = c.readyState;
            console.warn('forcing manually reconnect of mongoose connection');
            Raven.captureMessage('forcing manually reconnect of mongoose connection', {extra: {env: process.env, lastState}});
            // reconnect
            exports.reconnect()
                .catch((err) => {
                    Raven.captureException('forcing reconnect failed', {extra: {env: process.env, lastState, err}});
                    clearInterval(watchDog);
                    process.exit(3);
                });
        } else if (lastState[i] !== c.readyState) {
            lastState[i] = c.readyState;
        }
    });
}

and have an interval running that checks this every second.
It's only a temporary solution, but so far my situation with timing out healthchecks got better 👍

@vkarpov15
Copy link
Collaborator

@simllll do you have a way to repro this without using docker? It would definitely save me a lot of time if I didn't have to install and figure out docker to try to repro this.

@vkarpov15 vkarpov15 modified the milestones: 5.0.9, 5.0.10 Mar 5, 2018
@simllll
Copy link
Contributor

simllll commented Mar 5, 2018

@vkarpov15 I played around and found something "interesting". I don't even need to stop the mongos, it's enough to reduce the socket timeout. This script works without a docker, you need a mongos instance to connect to though.

const mongoose = require('mongoose');

const dburl = 'mongodb://127.0.0.1:27017/test';

const testSchema = mongoose.Schema(
    {
        test: String
    },
    {
        timestamps: true
    }
);

const MySchema = mongoose.model('TestSchema', testSchema);

mongoose.connect(dburl, {
    // loggerLevel: 'info',
    reconnectTries: 2, // increasing doesn't help
    reconnectInterval: 1000,
    connectTimeoutMS: 2000,
    socketTimeoutMS: 2000,
    poolSize: 1 // doesn't matter
});


// When successfully connected
mongoose.connection.on('connected', () => {
    console.log('dbevent: open');
});

// When successfully reconnected
mongoose.connection.on('reconnected', () => {
    console.log('dbevent: reconnected');
});

// If the connection throws an error
mongoose.connection.on('error', (err) => {
    console.log(`dbevent: error: ${err}`);
});

// When the connection is disconnected
mongoose.connection.on('disconnected', () => {
    console.log('dbevent: disconnected');
});

setInterval(() => {
    console.log('READYSTATE', mongoose.connection.readyState);
    for (let i = 0; i < 3; i++) {
        try {
            MySchema.findOne({}).exec()
                .then(res => console.log('db result:', res))
                .catch(e => console.log(e.message));
        } catch (e) {
            console.log(e.message);
        }
    }
}, 10000);

this script runs fine with local mongodb, it outputs stuff like this (my collection is empty):

dbevent: open
READYSTATE 1
db result: null
db result: null
db result: null
dbevent: reconnected
dbevent: reconnected
READYSTATE 1

but when I point it to a mongos instance, it does this:

dbevent: open
READYSTATE 1
dbevent: disconnected
READYSTATE 0
READYSTATE 0

I never get a result, and readystate is 0, even though if you set loggerLevel to 'info' you see a lot of reconnect events from the underyling driver:

[INFO-Server:26755] 1520289807028 server 127.0.0.1:27017 fired event reconnect out with message [object Object] { type: 'info',
  message: 'server 127.0.0.1:27017 fired event reconnect out with message [object Object]',
  className: 'Server',
  pid: 26755,
  date: 1520289807028 }

Could this be related to the "dbevent: disconnected"? I never call disconnect, I'm not sure why it does a disconnect.

let me know if this helps!

regards
Simon

@simllll
Copy link
Contributor

simllll commented Mar 6, 2018

Somehow I believe this is related to #6117. Today we ran into weird mongoose connection issues, which suddenly stopped. Now I just tried to open a mongo cli and also got connection issues on our test environment. Looked into it, and mongos reports too many open files (the test server has default ulimit settings). So somehow we reached more than 800 connections on our test enviornment. Poolsize is 5 on testing instances. So even if 10 or 20 instances would have been connected, this limit is by far not reached. And finally I see a lot of connection established events in mongos log:

2018-03-06T09:34:02.260+0000 I ACCESS   [conn2824] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.260+0000 I ACCESS   [conn2825] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.260+0000 I ACCESS   [conn2826] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.260+0000 I ACCESS   [conn2827] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.260+0000 I ACCESS   [conn2828] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.260+0000 I ACCESS   [conn2829] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.261+0000 I ACCESS   [conn2831] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.261+0000 I ACCESS   [conn2830] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.312+0000 I ACCESS   [conn2835] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.312+0000 I ACCESS   [conn2834] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.313+0000 I ACCESS   [conn2836] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.313+0000 I ACCESS   [conn2838] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.313+0000 I ACCESS   [conn2839] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2832] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2844] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2837] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2845] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2840] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2847] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2841] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2846] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2850] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.323+0000 I ACCESS   [conn2843] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2848] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.322+0000 I ACCESS   [conn2842] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.323+0000 I ACCESS   [conn2851] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.323+0000 I ACCESS   [conn2849] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.327+0000 I ACCESS   [conn2853] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.327+0000 I ACCESS   [conn2852] Successfully authenticated as principal hokify-test on hocknfinder-test-agenda
2018-03-06T09:34:02.401+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60384 #2854 (835 connections now open)
2018-03-06T09:34:02.401+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60386 #2855 (836 connections now open)
2018-03-06T09:34:02.401+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60388 #2856 (837 connections now open)
2018-03-06T09:34:02.407+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60390 #2857 (838 connections now open)
2018-03-06T09:34:02.408+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60392 #2858 (839 connections now open)
2018-03-06T09:34:02.414+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60394 #2859 (840 connections now open)
2018-03-06T09:34:02.414+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60396 #2860 (841 connections now open)
2018-03-06T09:34:02.414+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60398 #2861 (842 connections now open)
2018-03-06T09:34:02.433+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60400 #2862 (843 connections now open)
2018-03-06T09:34:02.433+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60402 #2863 (844 connections now open)
2018-03-06T09:34:02.433+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60404 #2864 (845 connections now open)
2018-03-06T09:34:02.433+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60406 #2865 (846 connections now open)
2018-03-06T09:34:02.434+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60408 #2866 (847 connections now open)
2018-03-06T09:34:02.434+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60410 #2867 (848 connections now open)
2018-03-06T09:34:02.439+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60412 #2868 (849 connections now open)
2018-03-06T09:34:02.439+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60414 #2869 (850 connections now open)
2018-03-06T09:34:02.439+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60416 #2870 (851 connections now open)
2018-03-06T09:34:02.439+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60418 #2871 (852 connections now open)
2018-03-06T09:34:02.439+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60420 #2872 (853 connections now open)
2018-03-06T09:34:02.439+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60422 #2873 (854 connections now open)
2018-03-06T09:34:02.441+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60424 #2874 (855 connections now open)
2018-03-06T09:34:02.441+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60426 #2875 (856 connections now open)
2018-03-06T09:34:02.442+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60428 #2876 (857 connections now open)
2018-03-06T09:34:02.442+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60430 #2877 (858 connections now open)
2018-03-06T09:34:02.445+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60432 #2878 (859 connections now open)
2018-03-06T09:34:02.445+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60434 #2879 (860 connections now open)
2018-03-06T09:34:02.445+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60436 #2880 (861 connections now open)
2018-03-06T09:34:02.445+0000 I NETWORK  [listener] connection accepted from 127.0.0.1:60438 #2881 (862 connections now open)

doesn't seem normal to me.

@simllll
Copy link
Contributor

simllll commented Mar 7, 2018

Tried to debug it a bit, but I'm kinda stuck.
Even if I try the experiment of @maloguertin, it doesn't work correctly. I get the reconnect event, and even the readystate goes back to 1, but the query is never executed.

dbevent: open
READYSTATE 1
close
dbevent: reconnected
READYSTATE 1
dbevent: reconnected

not a single line with "db result: undefined". If i run this query immediately after db connect, I get a result back (once).

Any ideas what's going on here?

Simon

@maloguertin
Copy link
Author

maloguertin commented Mar 7, 2018

@simllll are you running with mongos specifically?

@vkarpov15 You don't need docker, just a mongos so that the mongodb-core/lib/topologies/mongos.js is used

related issue on Jira: NODE-1340

@simllll
Copy link
Contributor

simllll commented Mar 7, 2018

@maloguertin yes, mongos. No issues with a single mongo instance!

@vkarpov15 vkarpov15 modified the milestones: 5.0.10, 5.0.11, 5.0.12 Mar 12, 2018
@vkarpov15 vkarpov15 modified the milestones: 5.0.12, 5.0.13 Mar 27, 2018
@vkarpov15 vkarpov15 modified the milestones: 5.0.13, 5.0.14, 5.0.15 Apr 5, 2018
@pelzerim
Copy link

I am experiencing this, too. Downgrading to 4.13.12 and explicitly using the decrepated connection logic by not using Mongo Client fixed it for now (useMongoClient: false in options). Be aware that the options object has a different structure in that version.

@vkarpov15 vkarpov15 removed this from the 5.0.15 milestone Apr 16, 2018
@vkarpov15 vkarpov15 removed this from the 5.2.4 milestone Jul 14, 2018
@pelzerim
Copy link

This issue still persists with our setup. When using a Mongos instance it can' reconnect. I tried our setup and the above script using mongoose@5.0.18 & mongoose@5.2.5, no reconnect.

@vkarpov15 vkarpov15 reopened this Jul 30, 2018
@vkarpov15 vkarpov15 added this to the 5.2.6 milestone Jul 30, 2018
@vkarpov15 vkarpov15 removed the needs repro script Maybe a bug, but no repro script. The issue reporter should create a script that demos the issue label Jul 30, 2018
@vkarpov15 vkarpov15 modified the milestones: 5.2.6, 5.2.7, 5.2.8 Jul 30, 2018
@lixiaolihua
Copy link

+1

@vkarpov15 vkarpov15 modified the milestones: 5.2.8, 5.2.9 Aug 12, 2018
@vkarpov15
Copy link
Collaborator

@pelzerim @lixiaolihua running locally I can confirm that the below successfully reconnects. Can you provide more info on what your mongoose connection looks like, like the general form of your connection string and the options you're using? Also, how long is your mongoose process disconnected from the mongos before the mongos comes back up?

const mongoose = require('mongoose');

const dburl = 'mongodb://127.0.0.1:51000/test';

const testSchema = mongoose.Schema(
    {
        test: String
    },
    {
        timestamps: true
    }
);

const MySchema = mongoose.model('TestSchema', testSchema);

mongoose.connect(dburl, {
    // loggerLevel: 'info',
    reconnectTries: 2, // increasing doesn't help
    reconnectInterval: 1000,
    connectTimeoutMS: 2000,
    socketTimeoutMS: 2000,
    poolSize: 1 // doesn't matter
});

// When successfully connected
mongoose.connection.on('connected', () => {
    console.log('dbevent: open');
});

// When successfully reconnected
mongoose.connection.on('reconnected', () => {
    console.log('dbevent: reconnected');
});

// If the connection throws an error
mongoose.connection.on('error', (err) => {
    console.log(`dbevent: error: ${err}`);
});

// When the connection is disconnected
mongoose.connection.on('disconnected', () => {
    console.log('dbevent: disconnected');
});

setInterval(() => {
    console.log('READYSTATE', mongoose.connection.readyState);
    for (let i = 0; i < 3; i++) {
        try {
            MySchema.findOne({}).exec()
                .then(res => console.log('db result:', res))
                .catch(e => console.log('Error', e.message));
        } catch (e) {
            console.log('SyncError', e.message);
        }
    }
}, 10000);

@vkarpov15 vkarpov15 added can't reproduce Mongoose devs have been unable to reproduce this issue. Close after 14 days of inactivity. and removed underlying library issue This issue is a bug with an underlying library, like the MongoDB driver or mongodb-core labels Aug 17, 2018
@vkarpov15 vkarpov15 removed this from the 5.2.9 milestone Aug 17, 2018
@fluxsauce
Copy link

We had experienced it when Mongo was configured to restart for log rotation. Our mitigation was to use a better method for log rotation that didn't involve restarting Mongo.

@pelzerim
Copy link

pelzerim commented Aug 21, 2018

@vkarpov15 I adapted the above script to our infrastructure (using ssl):

const mongoose = require('mongoose');

const dburl = 'mongodb://user:password@localhost:27017/test';

const testSchema = mongoose.Schema(
    {  test: String },
    {  timestamps: true  }
);

const MySchema = mongoose.model('TestSchema', testSchema);

mongoose.connect(dburl, {
    ssl:true,
    sslValidate: false,
    authSource: 'admin',
    reconnectTries: 30,
    reconnectInterval: 1000,
    connectTimeoutMS: 2000,
    socketTimeoutMS: 2000,
    poolSize: 1
});
[...]

yields

dbevent: open
READYSTATE 1
db result: null
db result: null
db result: null
READYSTATE 1
db result: null
db result: null
db result: null
READYSTATE 1
[mongos container restarted]
dbevent: disconnected
READYSTATE 0
[mongos running again]
db result: null
db result: null
db result: null
db result: null
db result: null
db result: null
READYSTATE 0
[...]

@vkarpov15
Copy link
Collaborator

@pelzerim I don't see what the problem is, your output just shows mongoose getting disconnected. Do you kill the mongos that mongoose is connected to and then restart it?

@pelzerim
Copy link

@vkarpov15 Yes, i restarted the container running mongos (takes around 3-5 seconds). I added the actions to the above logs. mongoose or MongoClient never reconnect. Can i provide you with more specific information?

@vkarpov15
Copy link
Collaborator

Hmm what does your container setup look like? Can you show your docker-compose file or equivalent?

@yuklia
Copy link

yuklia commented Oct 9, 2018

@vkarpov15 , Why this issue closed?
mongoose still has an issue with autoReconnect.

"mongoose": "^5.2.14"

mongoose.connect(config.mongodb.uri, {
    loggerLevel: 'info',
    reconnectTries: Number.MAX_VALUE,
    reconnectInterval: 500,
}).then(() => {});
mongoose.connection.on('reconnected', function () {
    console.log('MongoDB reconnected!');
});

Reconnect event never arises.

@vkarpov15
Copy link
Collaborator

@yuklia because to the best of our knowledge this issue is fixed. Can you modify the script from #6140 (comment) to repro your issue, and clarify your exact versions of MongoDB and mongoose please?

@pelzerim
Copy link

This seems to have been fixed in the underlying library! The latest mongoose I tested works (5.5.3).

@simllll
Copy link
Contributor

simllll commented Apr 24, 2019

I can confirm that this has been fixed in latest mongo library 3.2.3. Mongoose uses 3.2.2 though?

@elizatlawy
Copy link

I am using Node.js 14.18.3, mongoose 6.10.1, mongodb driver: 4.17.2 and Mongo version 5.0.9 and I'm having the same issue, no reconnect attempt after a disconnection.

My connection options looks like this:


const OPTIONS = {
  useNewUrlParser: true,
  useUnifiedTopology: true,
  serverSelectionTimeoutMS: 5000, // Timeout after 5s instead of 30s
  socketTimeoutMS: 45000 // Close sockets after 45 seconds of inactivity
};

@vkarpov15
Copy link
Collaborator

@elizatlawy can you please elaborate on how you're determining that no reconnect attempt is made after a disconnection? Do your queries still fail after your MongoDB server is back?

@elizatlawy
Copy link

@vkarpov15

  1. I am not getting the reconnected event.
  2. Yes my queries are failing after the Mongo server is back & once I restart the Node.js server it can connect successfully.

I have opened a separate ticket for my issue: #14517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
can't reproduce Mongoose devs have been unable to reproduce this issue. Close after 14 days of inactivity.
Projects
None yet
Development

No branches or pull requests

9 participants