SimpleXmlRpcServer _sock.rcv se fige après des milliers de demandes

Question

Je traite des demandes provenant de plusieurs clients XMLRPC via le réseau étendu. La chose fonctionne très bien pour, disons, une période d'un jour (parfois deux), puis se fige dans socket.py:

data = self._sock.recv(self._rbufsize) 

_sock.timeout est -1, _sock.gettimeout est Aucun

Il Je n'ai rien de spécial dans le thread principal (je ne reçois que des appels XMLRPC), il y a deux autres threads qui discutent avec DB. Ces deux threads fonctionnent bien et survivent à ce bloc (fait une vérification avec WinPdb). Les clients envoient des requêtes ne dépassant pas 1 Ko, et il n'y a pas de contenu spécial: juste des chaînes sympas et propres dans le dictionnaire. Entre deux blocages, je réponds à des dizaines de milliers de demandes sans problèmes. Pare-feu est éteint, pas de logiciel étrange sur la même machine, etc ...

J'utilise Windows XP et Python 2.6.4. J'ai vérifié les différences entre 2.6.4. et 2.6.5, et n'a rien trouvé d'important (ou est-ce que je me trompe?). La version 2.7 n'est pas une option car les binaires pour MySqlDB me manqueraient.

La seule chose qui arrive de temps en temps causée par les clients qui ont une mauvaise connexion Internet est que les sockets se brisent. Cela se produit toutes les 5-10 minutes (il y a seulement cinq clients qui accèdent au serveur toutes les 2 secondes).

J'ai passé beaucoup de temps sur cette question, maintenant je commence à perdre des idées quoi faire. Toute allusion ou pensée serait très appréciée.

Answer 1

Qu'est-ce qui se passe exactement dans la pile TCP/IP de votre système d'exploitation (peut-être dans les couches python en haut, mais c'est moins probable) pour causer cela est un mystère. Comme solution de contournement pratique, je définirais un délai d'expiration plus long que les délais attendus entre les demandes (10 secondes devraient être suffisantes si vous attendez une demande toutes les 2 secondes) et, le cas échéant, fermez et rouvrez. (Étalonnez le délai nécessaire pour contourner les gels sans interrompre le trafic normal par essais et erreurs). Je sais qu'il est désagréable de pirater un correctif sans comprendre le problème, mais être pragmatique à propos de telles choses est un trait de survie nécessaire dans le monde de l'écriture, du déploiement et de l'exploitation de systèmes de serveurs réels. Veillez à commenter la solution de contournement avec précision pour les futurs responsables!

Answer 2

merci beaucoup pour la réponse rapide. Juste après que je l'ai reçu j'ai augmenté le délai d'attente à 10 secondes. Maintenant, tout fonctionne sans problème, mais bien sûr, j'aurais besoin d'attendre un jour ou deux pour avoir une sorte de confirmation, mais seulement après 5 jours, je serai sûr et je reviendrai avec les résultats. Je vois maintenant que la requête de 140K s'est bien passée, ayant une expérience si dure sur celui-ci, j'attendrais au moins 200K supplémentaires.

Ce que vous proposiez sur l'adaptation automatique des délais d'attente (sans mettre le système en panne) semble également raisonnable. Est-ce que la bonne façon de procéder serait de créer une petite classe (par exemple AutoTimeoutCalibrator) et de l'intégrer directement dans serial.py? Oui, être pragmatique est le seul moyen sans perdre 10 jours de plus à essayer de comprendre la véritable raison derrière.

Merci encore, je serai de retour avec les résultats. (désolé, mais pour une raison quelconque, je n'ai pas pu le poster comme une réponse à votre poste)