Mongoose: 4.7.1 => 4.7.2 : Connexion MongoError expirée

Je rencontre le même problème, [email protected] , [email protected]

• définir socketTimeoutMS sur des valeurs plus élevées ou 0 ne fait aucune différence
• définir connectTimeoutMS sur des valeurs plus élevées ou 0 ne fait aucune différence
• aucun événement "close" ou "reconnected" n'est déclenché, seulement un "timeout", ce qui entraîne une erreur Mongoose dans le rappel

Revenir à [email protected] / [email protected] résout le problème, c'est-à-dire ne provoque pas de délais d'attente

De [email protected] à 2.2.12, l'écouteur d'événement timeout est passé de "once" à "on", peut-être que cela a quelque chose à voir avec cela ?

Ou devrions-nous publier cela comme un problème dans le pilote natif mongodb ?

@silentjohnny Obtenir le même problème avec [email protected]

Je posterais un problème dans le pilote natif mongodb, la mangouste ne fait pas grand-chose en termes de connexion initiale.

Voici le pilote mongodb jira

Bizarre. Je rencontre le même problème mais avec [email protected] et supérieur qui utilise [email protected]
Avec [email protected] et [email protected] ça marche ! .
Ma requête agrégée est sans aucune option, donc je ne sais pas, c'est peut-être la différence entre moi et le problème d'origine @dcolens .

Quelqu'un a ouvert un problème avec le pilote natif ? pour que je puisse suivre...
En ce moment je reste avec [email protected]

[email protected] mis à jour vers [email protected] qui inclut un correctif pour surveiller le délai d'attente des opérations et générer un événement de délai d'attente sur les opérations en cours d'exécution @ 1284917

Bientôt, Mongoose mettra à jour [email protected] , je vais essayer.

Même problème pour moi, et je ne sais même pas si ce sont juste des agrégats de longue durée qui expirent, ou si c'est aléatoire et pas du tout un vrai délai d'attente. Il semble parfois qu'il s'éteigne presque immédiatement, mais d'autres fois, il dure environ 30 secondes. Dans ce cas particulier, j'ai quatre agrégats.execs en cours d'exécution en même temps.

Revenir à [email protected] et [email protected] corrige le problème, donc je le fais pour l'instant.

Cela devrait, espérons-le, être corrigé dans la prochaine version puisque mongoose 4.7.7 utilise [email protected]. Quoi qu'il en soit, ce n'est pas vraiment un problème de mangouste comme l'a dit @ vkarpov15 , mais plus à voir avec mongodb. Je vais fermer cela pour le moment, mais si vous rencontrez toujours le même problème après la prochaine version, vous devriez ouvrir un ticket ou un PR du côté de mongodb.

Je pense qu'il y a peut-être plus à ce problème qu'il n'y paraît. J'ai dû revenir à 4.4.20 pour arrêter complètement ces délais d'attente agrégés se produisant en toutes circonstances. 4.7.x et 4.6.x avaient tous deux de faux délais d'attente très rapides dans certaines circonstances d'exécutions simultanées multiples. J'ai sauté la version 4.5 et je suis directement revenu à une bonne version connue (4.4.20) que nous utilisons en production, et cela a complètement résolu le problème, mais TBH, je suis toujours mystifié par ce qui se passe. Je suis désolé de ne pas avoir d'autres données à ajouter, mais je ne sais pas s'il s'agit uniquement d'un problème lié à la version du pilote natif mongodb que mongoose utilise, ou s'il y a plus d'un facteur contributif au travail .

Avoir le même problème avec [email protected] et [email protected]. Les délais d'attente sont vraiment bizarres. Celle-ci est assez courte (environ 5s) et très reproductible mais d'autres requêtes prennent plus de 5s et n'expirent pas

Je suis certain que les délais d'attente sont souvent faux. Dans un scénario que j'examinais, j'ai lancé quatre opérations simultanées d'aggreggate.exec qui prennent environ 30 secondes. Un a expiré en 8 secondes, un a expiré en 20 secondes, mais les deux autres se sont terminés normalement en 30 secondes. La répétition provoquait un ordre de temporisation différent, mais toujours un résultat similaire. Je soupçonne que les délais d'attente sont définis de manière incorrecte sur les mauvaises connexions ou ne sont pas supprimés lorsqu'une opération se termine, de sorte qu'ils se déclenchent de manière inattendue lors d'un exec ultérieur. Quelque chose comme ça en tout cas. Malheureusement, je n'ai pas le temps pour le moment de m'y atteler.

[email protected] semble avoir résolu les délais d'attente pour moi. @steve-p-com comme vous le suggérez, les délais d'attente dans 4.7.2 étaient en effet faux et provoquaient l'émission d'événements d'erreur sur la mauvaise connexion, cela a été résolu par [email protected] et donc [email protected] devrait fonctionne bien dans votre cas. As-tu fait un test avec cette version ?

Je n'ai pas encore testé 4.7.9 ou 4.8.0, peut-être que [email protected] a introduit une régression, ce qui expliquerait le problème rencontré par @flosky . Ce délai d'expiration se produit-il également sur [email protected] ?

J'ai retesté avec 4.8.1 aujourd'hui et je n'ai eu aucun problème avec des délais d'attente inattendus. J'ai d'abord supprimé tous les caches npm et les caches de fil, puis zappé node_modules, puis tout réinstallé. Jusqu'ici tout va bien.

Cela m'arrive aussi avec 4.8.1. Je suis revenu sur de nombreuses versions de Mongoose et MongoDB et j'ai le problème tout le temps.

@thenitai avez-vous plus de contexte / pouvons-nous voir comment vous configurez votre connexion mongoDB ?

@varunjayaraman J'ai trouvé que notre code d'erreur de domaine attrape l'erreur et redémarre donc notre application. Cependant, le problème est toujours là.

Vous ne savez pas exactement ce que vous devez voir dans la configuration de notre connexion. Vous voulez dire les options de connexion ? Si oui, ce sont :

var dbOptions = {
            db: { native_parser: true },
            server: {
                auto_reconnect: true,
                socketOptions: {
                    keepAlive: 1, 
                    connectTimeoutMS: 300000,
                    socketTimeoutMS: 300000
                }
            }
        };

J'ai aussi le même problème. même avec la dernière version v4.8.4

vient de trouver le prob. dans mon cas, c'est parce que l'utilisation de la mémoire du serveur est trop élevée (toujours 95% ~ 99%), après une augmentation de la mémoire, plus de problème.

Je vois aussi ce problème sur mon serveur avec Mongoose 4.7.7 , MongoDB 3.4.1 et Node 4.7.2 . Lorsque l'utilisation de la mémoire est élevée sur mon serveur, les délais d'attente semblent se produire de manière aléatoire en série :

CosWebsite-27 MongoError: connection 42 to 127.0.0.1:27017 timed out
CosWebsite-27     at Function.MongoError.create (/home/cos/cos/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:29:11)
CosWebsite-27     at Socket.<anonymous> (/home/cos/cos/node_modules/mongodb/node_modules/mongodb-core/lib/connection/connection.js:186:20)
CosWebsite-27     at Socket.g (events.js:260:16)
CosWebsite-27     at emitNone (events.js:67:13)
CosWebsite-27     at Socket.emit (events.js:166:7)
CosWebsite-27     at Socket.wrapped (/home/cos/cos/node_modules/newrelic/lib/transaction/tracer/index.js:183:28)
CosWebsite-27     at Socket.wrappedEmit [as emit] (/home/cos/cos/node_modules/newrelic/lib/transaction/tracer/index.js:220:46)
CosWebsite-27     at Socket._onTimeout (net.js:333:8)
CosWebsite-27     at _runOnTimeout (timers.js:537:11)
CosWebsite-27     at _makeTimerTimeout (timers.js:528:3)
CosWebsite-27     at Timer.unrefTimeout (timers.js:597:5)
... times 6
CosWebsite-27 GET /clans/compas-c-r-98QP9J2G/members 500 10569.300 ms - 9893
CosWebsite-27 GET /players/1000-99JQVQ9VU 500 12388.484 ms - 9849
CosWebsite-27 GET /players/R0YUPPRR/profile 500 8204.622 ms - 9857
CosWebsite-27 GET /players/UG8YJUJY/profile 500 4622.819 ms - 9857
CosWebsite-27 GET /clans/next-state-P8RYGQYV 500 11526.859 ms - 9861
CosWebsite-27 GET /clans/YY2CCUVV 500 6755.380 ms - 9817

Comme vous pouvez le voir, aucune demande n'a duré plus de 12 secondes. Mon connecteur mangouste est configuré de cette façon :

const mongoDB = {
    uri: "mongodb://127.0.0.1:27017/XXX",
    options: {
        host: '127.0.0.1',
        port: '27017',
        database: "XXX",
        compression: false,
        server: {
            poolSize: 5,
            auto_reconnect: true,
            socketOptions: {
                socketTimeoutMS: 0,
                connectTimeoutMS: 0
            }
        },
        promiseLibrary: Promise
    }
};

Une idée de ce qui pourrait mal se passer ?

@adrienbaron Moi aussi !!!
quelqu'un s'il vous plaît aidez-moi.

Quelqu'un a-t-il déposé un rapport de bogue aux développeurs du pilote natif mongo ?

ce problème existe-t-il toujours dans 4.9.1 ?

Oui, le problème existe toujours dans 4.9.1....

[email protected]
[email protected]
[email protected]

J'ai eu le même problème aujourd'hui après la mise à jour vers la dernière version de mangouste, que j'ai rétrogradé à 4.7.1 et tout fonctionne parfaitement !

Le problème n'est pas résolu depuis un certain temps maintenant.
Que devons-nous faire pour résoudre ce problème ?
À un moment donné, j'aimerais mettre à jour la version récente, mais je ne peux le faire que lorsque cela a été résolu.

J'ai mis à jour Mongoose de 4.4.17 à 4.7.9 il y a environ un mois. Depuis lors, un cronjob quotidien a commis trois erreurs, toujours avec une erreur de délai d'attente de connexion mongo.

Je vais passer à Mongoose 4.7.1 et voir si cela aide.

edit : le message d'erreur

2017-04-19 03:09:23: You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
MongoError: connection 261 to localhost:27017 timed out
    at Function.MongoError.create (/var/www/someproject/node_modules/mongodb-core/lib/error.js:29:11)
    at Socket.<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/connection.js:186:20)
    at Socket.g (events.js:286:16)
    at emitNone (events.js:86:13)
    at Socket.emit (events.js:185:7)
    at Socket._onTimeout (net.js:333:8)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

@centigrade-thomas-becker J'ai eu le même problème pendant plus d'un mois en production, je suis revenu à 4.7.1 hier, plus de problèmes !

le même problème se produit @ 4.7.7

Avec Mongo 4.7.1, il y a moins de problèmes qu'avec 4.7.9, mais je reçois toujours le message d'erreur occasionnel lors de l'enregistrement dans MongoDB :

2017-04-30 03:09:32: Error: connection timeout
    at .<anonymous> (/var/www/someproject/node_modules/mongoose/lib/drivers/node-mongodb-native/connection.js:168:17)
    at emitTwo (events.js:106:13)
    at emit (events.js:191:7)
    at listener (/var/www/someproject/node_modules/mongodb/lib/db.js:1791:14)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb/lib/server.js:270:14)
    at g (events.js:286:16)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/topologies/server.js:322:12)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at .<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/pool.js:271:12)
    at g (events.js:286:16)
    at emitTwo (events.js:106:13)
    at emit (events.js:191:7)
    at Socket.<anonymous> (/var/www/someproject/node_modules/mongodb-core/lib/connection/connection.js:175:10)
    at Socket.g (events.js:286:16)
    at emitNone (events.js:86:13)
    at Socket.emit (events.js:185:7)
    at Socket._onTimeout (net.js:333:8)
    at tryOnTimeout (timers.js:224:11)
    at Timer.listOnTimeout (timers.js:198:5)

L'erreur se produit sur une machine virtuelle Linux exécutant Ubuntu 15.04

Pareil ici avec :

├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]

version mongo @ 3.2.11

sur AWS EC2.

Une mise à jour/solution de contournement ? Est-ce que keepAlive: true aurait un effet positif ?

Je ne sais pas si cela aide quelqu'un, mais dans notre cas, nous avons remarqué que nous passions nos paramètres de délai d'attente ( socketTimeoutMS etc.) à travers options.server . C'était _faux_ ! Nous utilisons un jeu de réplicas et en tant que tel, nos options devraient avoir comme ci-dessous :

Dans notre cas, l'application avait en fait besoin de pouvoir se connecter à une réplique ou à un serveur normal. Nous avons donc :

const serverOptions = {
  poolSize: 100,
  socketOptions: {
    socketTimeoutMS: 60000
  }
};

mongoose.createConnection(dbpath, {
  server: serverOptions,
  replset: serverOptions
});

J'espère que cela aide quelqu'un!

Bonjour à tous,
J'utilise mlab pour héberger ma base de données. J'obtiens cette erreur
Erreur de connexion Mongo DB : {[MongoError : connexion 0 à ds155841.mlab. com:xxxxx a expiré'}

@RemeAjayi Je pense que cela n'a rien à voir avec ce billet.
Vous devriez essayer / en créer un autre après avoir creusé le problème.

@ht2 tu as sauvé ma journée ❤️

Existe-t-il une solution viable au problème d'origine?

Au cas où cela aiderait quelqu'un, j'ai rencontré ce problème lors de la parallélisation de 2 requêtes brutales find() (en utilisant le modèle Promise).

Tournant

Promise.all([
  col1.find({longQuery: true}),
  col2.find({longQuery: true})
])
.spread(function(result1, result2) {
  //stuff
});

dans une approche séquentielle

col1.find({longQuery: true})
.then(function(result1) {
  return Promise.all([
    result1,
    col2.find({longQuery: true})
  ]);
})
.spread(function(result1, result2) {
  //stuff
});

Ça a marché

@cyrilchapon pensait que cela fonctionnait pour moi mais votre approche séquentielle n'a pas résolu mon problème :/

c'est intermittent.. parfois ça marche, parfois ça s'arrête..

Pourquoi cette fermeture silencieuse ?

Une suite à mon commentaire précédent https://github.com/Automattic/mongoose/issues/4789#issuecomment -298849907

J'ai déplacé la base de données incriminée d'une machine virtuelle vers un conteneur docker avec les tout nouveaux linux, nodeJS et mongoDB. J'ai créé un test de résistance qui ne fait que tronquer et remplir la base de données toute la journée. J'ai constaté qu'environ 1 test sur 6000 entraîne une erreur de délai d'attente.

J'ai eu je suppose la même expérience après mon dernier commentaire, j'ai oublié de le mentionner.

Mais la mise à jour du nœud vers l'une de ses dernières versions avec tous les autres départements a apparemment fait l'affaire.

Maintenant, avec le commentaire ci-dessus, je pense que c'est une question d'erreur héritée

J'avais aussi le même problème avec mongo 3.6.2 et mongoose 4.9.2
Je l'ai corrigé en passant des paramètres de connexion supplémentaires

MONGO_URI=mongodb://user:[email protected]:27017/dbname?keepAlive=true&poolSize=30&autoReconnect=true&socketTimeoutMS=360000&connectTimeoutMS=360000

@mzahidriaz Merci beaucoup, vos solutions fonctionnent pour moi, mais pouvez-vous expliquer ou renvoyer un lien vers la façon dont vous avez choisi ces paramètres pour résoudre ce problème ?

@ MinhNguyen41092 pour le moment, les seuls documents sont les documents du pilote MongoDB http://mongodb.github.io/node-mongodb-native/3.1/api/MongoClient.html#connect . nous ajouterons des détails à ce sujet à http://mongoosejs.com/docs/connections.html

Pour ceux qui rencontrent des erreurs intermittentes, j'en avais aussi sur mongoose-4.13.11 avec mongodb-2.2.35 mongodb-core-2.1.19 dans un environnement particulier. Diverses requêtes à différents points de notre suite de tests, bien que testant principalement une partie particulière de notre application qui a des requêtes plus lourdes et font des choses en parallèle IIRC, recevaient toutes ce message d'erreur. Et l'ensemble de la suite de tests ne prend même pas 15 secondes pour s'exécuter, il n'y a donc aucun moyen que j'aie dû atteindre les délais d'attente intégrés par défaut de 30 secondes :

     MongoError: connection 0 to localhost:27017 timed out
      at Function.MongoError.create (node_modules/mongoose/node_modules/mongodb-core/lib/error.js:29:11)
      at Socket.<anonymous> (node_modules/mongoose/node_modules/mongodb-core/lib/connection/connection.js:200:20)
      at Socket._onTimeout (net.js:448:8)

Cela ne s'est produit que dans notre serveur de build de test CI. Je n'ai pas pu le reproduire sur ma machine de développement.

(Dans mon propre système (dépôt privé, c'est pour ma propre référence au cas où j'aurais besoin de creuser à nouveau), cette erreur apparaît au moins dans les numéros de build 358, 356, 355, 352).

Après avoir activé useMongoClient: true , les tests semblent réussir de manière fiable dans l'environnement CI jusqu'à présent. J'ai eu trois exécutions réussies avec seulement ce changement alors que de nombreuses exécutions séquentielles précédentes échouent en raison de l'étrange erreur de délai d'attente.

Je pense que @thenitai @steve-p-com @adrienbaron subissait aussi les faux délais d'attente étranges. Je pense que l'erreur vous arrivait avant la sortie du 4.11, ce qui a même apporté useMongoClient: true en option. Pouvez-vous dire si cela a fait la différence pour vos charges de travail ?

[email protected]
[email protected]
[email protected]
Vous avez le même problème, 1,5 M d'erreurs dans l'arceau de sécurité pendant quelques jours, avec quoi peut-il être connecté ? Comment résoudre?

@SergeyVatz voir réponse à votre question sur #5376