[TCP] Time out de 30s dans un échange HTTP [Résolu]

[nuke_y]

Bonjour à tous.

J'ai un problème compliqué et assez bloquant chez un de mes clients. Le logiciel impacté est Business Objects XI R2 SP3 (au cas où ça serve).

Ce logiciel peut fonctionner en mode 3 tiers :
- un client lourd sur le poste client
- un serveur d'application sur le serveur (en l'occurence IIS 6.0 sur un Windows 2003 Server SP3)
- des bases de données attaquées par le serveur d'application (ici du Oracle 9i et du 10g)
Ce qui est important c'est que dans ce mode là les BDD ne sont jamais attaquées par le client lourd.

Notre problème est que quand on lance une requête de moins de 30s elle se comporte correctement, mais quand on lance une requête de plus de 30s, une erreur survient au bout de 30s en indiquant : Unexpected Behavior (le message utile, j'adore...). Là où c'est piquant, c'est que ce problème survient si le poste client est en Vista ou Win 2003 Server mais PAS en Windows 2000 Server. Nous n'avons pas pu tester XP malheureusement.

Nous avons testé chaque brique indépendamment pour comprendre et nous n'avons rien trouvé ni dans les paramètres de l'application, ni dans ceux d'IIS ni dans ceux de Windows 2003 Server. Nous avons bien évidemment cherché un timeout de 30s. Nos différents tests nous ont permis d'exclure :
- les BDD
- le mode de connexion (login/mdp ou SSO)
- le firewall (il n'y en a pas)
n'ont pas été exclus :
- la version d'IE (qui n'est pas utilisé, mais sait-on jamais) entre IE 6 et IE 7
- l'OS

Finalement nous en sommes arrivés à fouiller dans les trames avec ethereal pour trouver ce qu'il se passe au bout de 30s et surtout QUI coupe la communication entre le client et le serveur. Et là, surprise ! C'est VISTA qui coupe la communication au bout de 30s.

D'un point de vue protocole, disons que VISTA envoie un FIN ACK au bout de 30s alors que Win 2000 Server attends sagement. Derrière son FIN ACK (et l'ACK du serveur) VISTA tente de redemander la page mais il est débouté.

Alors je me demande si c'est bien normal que VISTA provoque cette coupure au bout de 30s. C'est dans la norme TCP ? C'est un paramètre ? Du genre do-plante-la-communication-au-bout-du-time-out-pour-faire-ch***-nuke_y : 30 ?

Je vous joins les screen des 2 traces, sur VISTA et Windows 2000 Server. On a pas les traces de Win 2003 (on va pas mettre ethereal sur un serveur) mais on suspecte la même cause. Le poste en VISTA a l'IP 31 (en rouge et noir), le poste en Windows 2000 Server a l'IP 230 (en rouge et noir) et le serveur a l'IP 39 (en noir et vert).

Les 1eres trames qui divergent entre les 2 cas sont en bleu et blanc :
- la trame de FIN par VISTA vers le serveur
- la trame NBSS du serveur vers Windows 2000 Server

Je suis ouvert à toute remarque et conseil. Du genre "le comportement de Vista est autorisé par les protocoles TCP et HTTP, il y a un problème du côté de votre serveur qui déboute le VISTA quand il tente sa reconnexion après avoir coupé la précédente".

Merci

[nuke_y]

Ca rox du popotin !!

On a trouvé : c'était EXACTEMENT ce qu'on pensait : de la sécurité sur IE 7 +(VISTA/Win2003). Enfin, on avait pas exclu IE7 même si ça nous semblait improbable...

On a abandonné IIS comme serveur d'application et on est passé à Tomcat pour voir. Et on a vu : ça nous a donné un autre message d'erreur. Pas forcément plus parlant, mais suffisant pour sortir des dizaines de sujets sur google. Et paf la solution était là, sous nos yeux : la solution.

Il suffisait en fait de rajouter une clé de registre ReceiveTimeout en lui donnant une valeur de plus de 30 secondes, car le time out de 30 secondes est codé en dur dans IE7.

Les conlusions à en tirer :
- le support BO c'est des glands. Genre tous les clients qui ont IE7 doivent avoir le problème et les mecs ils ont pas été foutus de chercher dans leur propre base de connaissance.
- dans IE 7 il y a des trucs codés en dur
- on est vraiment des tanches de pas arriver à faire une recherche google correcte.

Note : si quelqu'un me dit "ah ben oui, c'est super connu comme problème" je le bute

Merci à tous, et à la prochaine !

Encore une victoire de canard ! Coin ! Coin !

[Flamby38]

- le support BO c'est des glands.

ca je plussoie. J'ai aussi plein de problemes qui paraissent très classiques, ils mettent entre 3 semaines et un mois et demi pour me trouver une solution en général.

[nicroman]

Moi j'aime bien ça:

Il suffisait en fait de rajouter une clé de registre ReceiveTimeout en lui donnant une valeur de plus de 30 secondes, car le time out de 30 secondes est codé en dur dans IE7.

On doit pas avoir la même définition de 'codé en dur' !

Bon... je vais dire quelques trucs:

Une requête HTTP qui met plus de 30s à répondre est une reqûete foireuse... et (à mon avis) IE à bien raison de couper la comm assez vite (par défaut c'était 3 minutes avant si je me souviens bien). Une valeur par défaut (et non 'en dur') de 30s est pas forcément terrible, mais je ne suis pas sur qu'il existe une valeur terrible.

Ma raison de penser cela est la suivante:
Le fait est qu'un utilisateur lambda, qui ne vois rien arriver au bout de 10s (valeur empirique récupérée sur *nos* serveurs) fais un: refresh (F5)..., ou un close + re-open.... Résultat des courses DEUX requêtes lourdes à gérer simultanément par le serveur au lieu d'une seule... et si ca n'arrive pas plus vite... il laisse tomber (ou il réessaye ! )... Pour finir à 3/4 requêtes lourdes, du même client, inutiles (comm coupée), ... Bref, c'est du tout faux

Je sais , c'est gavant ces utilisateurs qui ne savent pas attendre, mais c'est comme ça... Et après avoir mis sur les genoux 4 serveurs en batterie (tomcat) à cause d'une requête foireuse, et d'un simple utilisateur lambda, on fait forcément attention à ces trucs....

Il y a plusieurs moyens de résoudre le problême:
- Faire en sorte que la requête réponde plus rapidement. C'est pas forcément faisable, mais en général, on y arrive quand même (DB index, optimisation du code, ajout de tables + triggers).
- Faire en sorte que la réponse à la requête soit "étagée" (faire un flush au milieu de la réponse, histoire d'envoyer tout le HTML initial). Ca permet au moins à l'utilisateur de voir qu'on va répondre... faut être patient.
- Faire en sorte que la réponse soit différée... C'est le plus propre, mais aussi le plus difficile à coder: Créer une "tâche" pour la partie longue de la requête, renvoyer un HTML avec un iFrame (ou du javascript) qui va vérifier toutes les X secondes l'état de la tâche, et ou bien afficher le résultat de celle-ci, ou afficher un "chargement des données...."...

[pape0]

Envoyé par nuke_y

Des requetes de 3 minutes

Pouha sa poc la requete qui n'utilisent pas les bons index, faut arreter!


Si tu as une requete qui dure plus de 30s(pour les premiers enregistrements) c'est que tu n'utilise pas les bons index,
ou qu'il n'y pas les bons index sur les tables.
Il faut verifier, et réécrire la requète (ou les index des tables)!

[nuke_y]

Merci des commentaires mais

1) la clé de registre est à CREER pas à MODIFIER, donc le time out de 30s est bien codé dans le code de IE, même s'il peut être écrasé par une clé de registre. Donc pour moi c'est codé en dur.

2) je suis bien d'accord que le protocole HTTP n'est pas un protocole fonctionnant en mode connecté et que donc il n'y a pas à considérer que l'émetteur de la requête doit attendre jusqu'à sa fin. Le problème c'est que c'est BO qui a programmé son serveur avec les pieds et qu'on ne peut rien y changer. Le plus drôle c'est que pour BO c'est un bug d'IE 7, j'adore

3) Il n'y a pas de "refresh" possible pendant qu'un autre tourne déjà sous BO 3-tiers, il faut soit lancer une 2e fois le programme soit couper le programme sauvagement. Donc peu de chance que l'utilisateur envoie la même requête 2 fois ou plus.

4) @nicroman : euh mais tu connais BO ou pas ? Parce que tout ce dont tu parles je vois pas le rapport avec BO...

5) @pape0 : je n'en suis pas sûr (pas testé, je le ferai ptet ce soir) mais je pense que BO en 3-Tiers attends d'avoir reçu toutes les données avant d'envoyer quoi que ce soit au client. Et 30s pour ramener plusieurs dizaines de milliers de lignes ben ça arrive, désolé. Au pire même si la requête est moisie mon taff ce n'était pas de l'optimiser mais d'intégrer BO XI donc ça ne réglait rien.

Enfin merci quand même