Le 3 avril 2013 12:07, Christian Quest <[email protected]> a écrit : > Le 3 avril 2013 11:26, Philippe Verdy <[email protected]> a écrit : >> Non tu te trompes là encore, c'est moi qui ait fermé cette relation >> modifiée sous JOSM, explicitement depuis JOSM (CTRL+ALT+Q), après >> avoir envoyé les modifs objet par objet. Et bel et bien une heure >> avant celle indiquée. L'heure de fermeture réelle affiché est bien >> décalée avec une heure de retard sur la réalité. >> > > Gros doute quand même sur cette "explication" car les changesets > suivants d'autre contributeurs sont en général refermés quelques > secondes après leur création. Si il y avait eu un tel problème avec > les heures de fermeture des changeset sur l'API ça aurait été général > et pas sur certains changesets et pas tous. > > Exemple: http://www.openstreetmap.org/browse/changeset/15569812
Tu peux en douter mais c'est pourtant bien le cas que dans la journée du 1er avril, on a eu droit à ces décalages d'une heure (et pas que moi d'ailleurs). Les fermetures de changeset ont une heure assez aléatoire, et je pense que dans la plupart des cas cela venait justement de ces changeset "bloqués" pour lesquels le serveur cessait de répondre au front-end de l'API, qui elle non plus pouvait ne rien répondre non plus et fermer la session HTTP brutalement après 2 ou 3 minutes. On ne peut plus détecter le problème aujourd'hui mais il a bien été présent après le redémarrage du serveur (sur un serveur de secours?) suite à la panne sérieuse du 30 sur ramoth. Un bloquage qui a conduit justement à ce que plusieurs autres changesets de ma part sont restés vides (peu importe d'ailleurs l'heure affichée, le fait est que rien ne passait dedans à cause de l'anomalie de non réponse du serveur lors de la soumission d'un objet). Exemple: http://www.openstreetmap.org/browse/changeset/15571074 (resté ouvert sans rien dedans, une erreur HTTP venant du serveur) http://www.openstreetmap.org/browse/changeset/15571095 (nouvelle tentative, certaines données sont passées, d'autres se sont bloquées) Ces deux là ont été fermés manuellement par moi avec CTRL+ALT+Q dans JOSM. A partir de 17 heures, cependant, on ne constate plus de décalage d'1 heure. Peut-être que le changement d'heure a été corrigé sur le serveur (ce qui a pu aussi causer des problèmes de synchro et de non-réponse du serveur). J'avais écrit pour signaler le problème au moment où il avait lieu, mais maintenant le problème ne se produit plus et il ne faut pas conclure sur ce qu'on voit maintenant, surtout quand on n'a aucune idée de ce qui a été fait sur les serveurs pour les remettre en service après la panne et la réparation d'urgence. De même j'ai pu constater qu'une partie des modifs envoyées et validées avec succès dans la journée du 1er avril ont été "oubliées" par le serveur (n notamment des erreurs signalées par Osmose et bel et bien corrigées le 1er avril, mais réapparu non corrigées du tout, sans aucun revert, le 2 avril : dans le nord de l'Allemagne notamment, ainsi que des nouveaux POIs ajoutés juste après le redémarrage, des fautes d'orthographe dans les noms corrigées le 1er mais réapparues le 2, là encore sans aucune trace de la correction qui n'apparait plus dans les changesets qui les avaient effectués). Autrement dit le serveur a été instable pendant une bonne partie de la journée du 1er avril, des modifs validées ayant pu être perdues et d'autres ayant pu rester bloquées sans aucune erreur rapportée au client hors de la fermeture de session HTTP sans réponse. La réparation des serveurs a semble-t-il été faite avec un redémarrage en mode dégradé mais avec aussi visiblement un processus effectuant en parallèle des vérifications d'intégrité, ce qui causait une charge importante sur le serveur et a pu conduire en cas de doute ou conflit à supprimer des modifs plus récentes pour revalider une modif plus ancienne datant de jute avant la panne. Pour l'instant je n'ai aucune explication concernant ces bloquages intempestifs sans réponse, et ces changesets créés avec succès mais restés désespérément vides de tout changement, ni pour les changeset bien effectuées et refermés correctement mais dont une partie des modifs a disparu sans plus aucune trace. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
