j'ai un serveur web de tornade, quelque chose comme:connexions Tornado qui ne ferment pas à freeBSD
app = tornado.web.Application(handlersList,log_function=printIt)
app.listen(port)
serverInstance = tornado.ioloop.IOLoop.instance()
serverInstance.start()
les gestionnaires sont faits avec tornado.web.RequestHandler
. Quand je lance le serveur sur freeBSD, parfois la page/ressource prend du temps à charger, essayant de déboguer je vois qu'en attendant la page à charger Tornado n'a pas encore créé d'objet de requête, et en regardant les résultats de netstat, je voir beaucoup de connexion avec le statut ESTABLISHED. Donc, je pense qu'il y a trop de connexions non fermées et que le système d'exploitation refuse une nouvelle connexion provenant de la même session.
Cela peut-il être le cas?
Je ne fais rien dans get, post fonctions après l'écriture, dois-je d'une certaine manière arrêter/fermer la connexion avant de revenir?
EDIT 1: get/post sont synchrones (pas @asynchronous)
EDIT 2: temporairement fixe en forçant no_keep_alive
class BasicFeedHandler(tornado.web.RequestHandler):
def finish(self, chunk=None):
self.request.connection.no_keep_alive = True
tornado.web.RequestHandler.finish(self, chunk)
Je ne suis pas sûr si les connexions keep_alive doivent rester ouverts si longtemps après connexion fermée du client, de toute façon cette solution de contournement fonctionne.
J'ai trouvé comment faire cela en regardant HTTPConnection._finish_request
, quand aucun keep-alive cette ligne self.stream.read_until(b("\r\n\r\n"), self._header_callback)
fonctionne. qu'est-ce que c'est \ r \ n \ r \ n dans ce contexte?
essayer d'appeler 'self.finish' si vous êtes dans le doute. –
Les méthodes get/set de vos gestionnaires sont-elles déclarées asynchrones? – lbolla
Cela semble être un problème connu avec de nombreuses plaintes sur la liste de diffusion concernant les descripteurs de fichiers qui fuient Tornado. –