-
Pas de timeout
Bonjour,
Dans le fichier httpd.conf, il y a la ligne "Timeout 300" qui définit un time out de 300 secondes. Est-il possible d'avoir un timeout illimité, c'est-à-dire pas de time out, car j'ai un cgi qui doit tourner sans être arrêter à cause du timeout.
Merci d'avance.
-
Peut-être essayer 0 mais j'ai des doutes que ça marche (la doc ne dit rien sur le fait qu'on puisse désactiver le timeout). Maintenant, désactiver le timeout, c'est une très mauvaise idée car en le faisant, c'est la porte grande ouverte à des attaques DoS par exemple. Et de toute façon, je pense que le noyau appliquera par dessus son propre timeout. D'où la question : pourquoi devoir appeler un CGI pour un traitement aussi long ? N'est pas possible de passer par un script standard avec éventuellement un ordonnanceur ?
-
Le cgi me permet d'avoir une connexion persistante avec un programme C++ par le biais des sockets. J'ai ainsi une communication entre mon programme C++ et le navigateur. Mais il se peut qu'il n'y a pas de transferts de données entre les 2 durant un certain temps qui est supérieur au timeout.
Une solution serait d'envoyer une donnée "bidon" dans la socket afin d'éviter le timeout.
Maintenant la question est lorsque le cgi est arrêté à cause d'un timeout, est-ce qu'il y a fuite de mémoire ; étant donné que le cgi est écrit en C++ ?
-
Ca, je ne sais pas s'il y a fuite mémoire ou pas. Le coup de l'envoi de données bidon, c'est du déjà vu, bien que pas très propre, mais si c'est la seule solution pour maintenir la connexion...
-
Donc en résumé , soit il faut créer un thread au niveau du cgi qui envoie régulièrement (temps inférieur au timeout) au browser (avec des printf) le statut de la connection avec le programme C++ ; soit il faut faire un timer en javascript qui recharge la page avant le timeout.
-
Si tu recharges la page, tu vas terminer le processus CGI en cours et en relancer un autre...
Le plus propre c'est que ton CGI soit exécuter par un ordonnanceur et qu'il écrive ce qu'il a à dire dans une base de données ou un fichier, et que ta page Web ne fasse que consulter la base de données ou le fichier. Comme ça, ton script tourne tranquillement dans son coin sans prendre le risque qu'il soit interrompu et tu peux consulter quand tu veux ce qu'il a dit.