Bonjour,
 
Ma boîte fournit une solution de saisie des temps/planification pour des entreprises de consulting. Les utilisateurs se connectent en web sur l'adresse IP de notre serveur qui héberge l'application, et un port propre à leur société et à leur version de l'application. Ils arrivent sur une page de connexion login/mot de passe, et en se connectant, ils tombent sur une page unique fonctionnant par onglets, AJAX, web services (la page n'est donc jamais rechargée tout le long de la navigation).
 
Actuellement j'ai des utilisateurs qui rencontrent un problème récurrent mais pas systématique : ils font leur vie sur la page web de l'appli (consulter leur planning, saisir des temps jour par jour, demander des congés, créer des notes de frais...), et toutes ces actions diverses provoquent le lancement de web services. J'en viens au problème : à un moment donné, il peut arriver, durant l'exécution d'un web service (à noter que ça se produit parfois dès la connexion), qu'ils aient un pop-up d'erreur avec un message de type : "http://ip:port/fichier.js" (avec évidemment l'IP du serveur, leur port dédié, et le nom d'un fichier JS de l'application). En validant ce message d'erreur ils retournent sur la page de connexion. Le nom du fichier JS est variable, j'imagine que ça dépend dans quel fichier JS se trouve le web service qui a planté (si ça plante lors d'une demande de congés, c'est le nom du fichier JS traitant les congés qui est afficher dans le pop-up).
 
J'ai pu obtenir un screen d'un utilisateur avec la console de Chrome ouverte, ce sera plus parlant :

 
J'ai évidemment cherché des infos sur ces messages d'erreur, mais rien ne semble correspondre à leur cas (version de Chrome, le fait que ce soit aléatoire, pare-feu...).
 
Voici quelques infos importantes :
- Actuellement sur les deux boîtes qui utilisent notre application (bêta-testeurs), ce sont les seuls a rencontré le problème
- Tous ces problèmes ont été constatés avec une connexion 4G
- Des speedtests ont été réalisés par les utilisateurs pile au moment du bug, et ils sont plus que corrects
- Ce bug dure généralement un laps de temps très court (il survient une fois, oblige l'utilisateur à se reconnecter, et ne survient plus avant un moment), mais c'est arrivé qu'il dure quelques secondes (il survient, oblige l'utilisateur à se reconnecter, et survient encore au moment de la reconnexion, nécessitant parfois trois ou quatre essais), voire quelques minutes
- J'utilise un service de monitoring qui teste la connexion à l'application sur leur port, avec un de leurs logins/mots de passe, toutes les minutes, et il n'a jamais relevé de problèmes (à part quand notre serveur a crashé )
- Nous n'avons jamais constaté ce problème durant le développant, soit des milliers d'essais sur plusieurs adresses (dont la leur)
 
Merci beaucoup.

 
Un problème au niveau de l'itinérance des données ?

 
 
Qu'entends-tu par là ? Tu parles de l'itinérance des données de manière générale, ou de l'option intitulée "Itinérance des données" qui sert à utiliser des réseaux mobiles d'autres opérateurs ?

T'as vu qu'en rouge, il indique un time out sur le chargement de ressource, j'imagine, le fichier js qui pose pb ?
 
Je pense que le pb se situe sur le transport des données (donc pb réseau et non applicatif), problème qu'on a peu de chance de rencontrer sur un réseau local de dév. Sans doute un pb transitoire et ponctuelle. A voir si en réduisant le poids des fichiers (si c'est possible) si ça le fait encore... Y'as des compacteurs de code js

 
Oui j'ai vu ce qu'il y a en rouge quand même Justement tout porte à croire que c'est un problème de réseau.
 
Les tests n'ont pas été faits que sur le réseau local de dév, l'appli est déployée en interne pour nos services et donc des mecs s'y connectent depuis chez eux ou d'autres villes en Wi-Fi ou Ethernet, et on n'a jamais eu un seul problème.
 
Mais j'y connais rien en réseaux, je suis étonné que leurs speedtests soient bons en même temps que le problème est présent. Mais oui je leur ai déjà signalé qu'un réseau 4G pouvait être instable et que la moindre microcoupure normalement invisible à l'utilisation pouvait du coup stopper net le fonctionnement.
 
Merci j'irai voir les compacteurs de code, et oui il y a sûrement beaucoup à faire pour améliorer le fonctionnement de l'appli et l'échange des données avec le serveur (pour te dire il n'y a pas de formulaires, que des web services et de l'AJAX, parfois plusieurs tournant en même temps).

Faudrait regarder à combien est fixé le timeout (au bout de combien de temps le navigateur laisse tomber le chargement d'une ressource). Est-ce en ms ou en secondes ?

 
+1
 
Et accessoirement, il faudrait aussi que l'applie prévoit ce genre de situation, gère l'erreur et éventuellement cherche à retenter 1 ou 2 fois in the background, puis, si ca ne marche toujours pas, alors afficher un message d'erreur personnalisé et non laisser le navigateur s'en charger.
 
Ca ressemble quand même à un truc un peu codé à l'arrache et/ou jamais complètement terminé.

OK merci je regarderai ça.
 

 
Ca c'est la version courte En vrai ça ressemble à trois développeurs juniors développant quatre applications en même temps sur trois langages différents et sur PC et mobiles en plus de faire du support technique et de gérer les problèmes de serveurs avec un turn-over important, pas de spécs écrite, pas de chef de projet, et un boss qui change d'avis toutes les semaines et qui pense qu'une appli mobile ça prend un mois à développer sur iOS quand on connaît même pas le langage  

Encore un projet bien parti
 
Tiens, tu passeras ces stats à ton Boss : http://fr.wikipedia.org/wiki/Project_management_office
Ca le fera peut-être réfléchir et à changer de méthode...

Hello,
 
Je reviens aux nouvelles avec quelques précisions :
- les fichiers JS font entre 600 et 3500 lignes chacun
- chacun des modules "Timesheet", "Frais", "Planning" et "Congés" (c'est-à-dire les quatre fichiers JS correspondant) est chargé via un webservice à l'ouverture du site
- ces modules comptent eux-mêmes plusieurs webservices qui seront lancés lors de diverses actions de l'utilisateur (parfois très rapidement voire en même temps)
 
Sinon effectivement il n'y a pas de gestion de timeout ni d'erreur pour le timeout (d'autres erreurs sont gérées quand même).

Bonjour,
 
Pourriez-vous m'indiquer où se paramètre le timeout/retry sur un web service et comment gérer les erreurs qui en découlent ?
 
Merci.

 
?? ben ca dépend complètement comment a été programmé le bouzin... Si c'est basé sur jquery, ca se gère directement sur les appels Ajax.

La partie client combine YUI et JQuery mais il n'y a absolument rien sur un quelconque timeout.
 
La partie serveur est en 4D. Oui oui c'est un langage qui existe... Ça doit sûrement être là...
 
Voici la fonction JS utilisée pour tous les webservices (perso j'y pige rien) :
 

Bonjour,
 
Le problème est toujours là mais j'ai une nouvelle piste, une erreur qui apparaît dans la console de Chrome lorsque le plantage survient : Failed to load resource: net::ERR_EMPTY_RESPONSE.
 
J'ai vu sur le net que ça pouvait être propre à Chrome et à un problème de cache du PC voire du routeur. J'ai testé avec FireFox chez le client où ça plante souvent avec Chrome et effectivement ça fonctionnait nickel avec le renard alors qu'en même temps ça plantait avec Chrome.
 
Ceci dit je reste dubitatif, je pense que c'est seulement une partie du problème, parce que leurs autres applications ne plantent pas spécialement avec Chrome, et en plus ça le fait pas systématiquement, et pas à tout le monde.
 
Ça vous donne des idées ?
 
Merci.