MISE À JOUR :Notre article d'assistance pour ce sujet (essentiellement une copie de ce message) a été déplacé vers notre document de dépannage de connexion.
Il existe un problème connu selon lequel le réseau Azure IaaS applique un délai d'inactivité d'environ treize minutes (calcul empirique). Nous travaillons avec Azure pour voir si nous ne pouvons pas rendre les choses plus conviviales, mais entre-temps, d'autres ont réussi en configurant leurs options de pilote pour contourner le problème.
Durée maximale d'inactivité de la connexion
La solution de contournement la plus efficace que nous ayons trouvée en travaillant avec Azure et nos clients a été de définir le temps d'inactivité maximal de la connexion en dessous de quatre minutes. L'idée est de faire en sorte que le pilote recycle les connexions inactives avant que le pare-feu ne force le problème. Par exemple, un client, qui utilise le pilote C#, a défini MongoDefaults.MaxConnectionIdleTime à une minute et cela a résolu leurs problèmes.
MongoDefaults.MaxConnectionIdleTime = TimeSpan.FromMinutes(1);
Le code d'application lui-même n'a pas changé, mais maintenant, dans les coulisses, le pilote recycle agressivement les connexions inactives. Le résultat peut également être vu dans les journaux du serveur :beaucoup d'attrition de connexion pendant les périodes d'inactivité dans l'application.
Il y a plus de détails sur cette approche dans le thread mongo-user connexe, SocketException utilisant le pilote C# sur azur.
Garder en direct
Vous pouvez également contourner le problème en rendant vos connexions moins inactives avec une sorte de keepalive. C'est un peu délicat à mettre en œuvre à moins que votre pilote ne le prenne en charge par défaut, généralement en tirant parti de TCP Keepalive. Si vous avez besoin de lancer le vôtre, assurez-vous de saisir chaque connexion inactive du pool toutes les deux minutes et d'émettre une commande simple et bon marché, probablement un ping.
Gérer les déconnexions
Des déconnexions peuvent se produire de temps en temps, même sans une configuration de pare-feu agressive. Avant de vous lancer dans la production, vous voulez vous assurer de les gérer correctement.
Tout d'abord, assurez-vous d'activer la reconnexion automatique. La façon de procéder varie d'un pilote à l'autre, mais lorsque le pilote détecte qu'une opération a échoué parce que la connexion était mauvaise, l'activation de la reconnexion automatique indique au pilote d'essayer de se reconnecter.
Mais cela ne résout pas complètement le problème. Vous avez toujours le problème de savoir quoi faire avec l'opération ayant échoué qui a déclenché la reconnexion. La reconnexion automatique ne relance pas automatiquement les opérations ayant échoué. Ce serait dangereux, surtout pour les écrivains. Donc, généralement, une exception est levée et l'application est invitée à la gérer. Souvent, réessayer des lectures est une évidence. Mais les nouvelles tentatives d'écriture doivent être soigneusement envisagées.
La session mongo shell ci-dessous illustre le problème. Le shell mongo a par défaut la reconnexion automatique activée. J'insère un document dans une collection nommée stuff puis recherchez tous les documents de cette collection. J'ai ensuite réglé une minuterie sur trente minutes et j'ai essayé à nouveau la même trouvaille. Cela a échoué, mais le shell s'est automatiquement reconnecté et lorsque j'ai immédiatement réessayé ma recherche, cela a fonctionné comme prévu.
% mongo ds012345.mongolab.com:12345/mydatabase -u *** -p ***
MongoDB shell version: 2.2.2
connecting to: ds012345.mongolab.com:12345/mydatabase
> db.stuff.insert({})
> db.stuff.find()
{ "_id" : ObjectId("50f9b77c27b2e67041fd2245") }
> db.stuff.find()
Fri Jan 18 13:29:28 Socket recv() errno:60 Operation timed out 192.168.1.111:12345
Fri Jan 18 13:29:28 SocketException: remote: 192.168.1.111:12345 error: 9001 socket exception [1] server [192.168.1.111:12345]
Fri Jan 18 13:29:28 DBClientCursor::init call() failed
Fri Jan 18 13:29:28 query failed : mydatabase.stuff {} to: ds012345.mongolab.com:12345
Error: error doing query: failed
Fri Jan 18 13:29:28 trying reconnect to ds012345.mongolab.com:12345
Fri Jan 18 13:29:28 reconnect ds012345.mongolab.com:12345 ok
> db.stuff.find()
{ "_id" : ObjectId("50f9b77c27b2e67041fd2245") }
Nous sommes là pour vous aider
Bien sûr, si vous avez des questions, n'hésitez pas à nous contacter à [email protected] Nous sommes là pour vous aider.
