Le 18 février 2013 23:05, Christian Quest <[email protected]> a écrit : > * à part ces doublons créés par JOSM et les serveurs OSM... du jamais vu > jusque là il fallait que ça tombe sur Philippe !
Je connais un cas pas si rare que ça : c'est quand pour une raison ou une autre la session HTTP tombe en cours de route : JOSM ne signale rien du tout mais arrêt l'upload en laissant des objets orphelins ou des objets qui auraient du être affacés à la fin. On s'en rend compte uniquement parce que le changeset n'est pas fermé : c'est pour ça qu'après un upload j'appuie sur CTRL+ALT+Q pour vérifier que le changeset est bien fermé et complet et n'a pas été interrompu en cours. Et c'"était justement le cas lors de l'import qui a raté avec toutes les créations d'objets en double (alors que ce sont normalement les premières à être envoyées, avant les modifs et les suppression à la fin, mais le changeset contenait bien le tout : créations, modifs, et suppressions c'est la première partie qui s'est exécutée deux fois sur le serveur et dans la même session HTTP car les IDs que j'avais dans mon fichier OSM étaient ceux de la seconde version, et aucun de la première version envooyée par JOSM). J'ai ce genre d'erreur beaucoup plus souvent si je laisse JOSM tout envoyer en une seule transaction: pour limiter les dégats je lui fait envoyer les objets par petits paquets de 5 objets maxi (il faut plus de requêtes mais elles sont moins lourdes sur le serveur, il y a moins de chance que la session tombe pendant l'exécution d'une grosse requête) ; cela allège énormément aussi le temps pour résoudre les conflits, même si quand il y en a un je vais systématiquement faire CTRL+ALT+M après pour resynchroniser tous les autres objets en cours de modif et qui n'ont pas encore été envoyés et marqués en conflit par le serveur. Ca permet aussi de limiter énormément le nombre de conflits à résoudre pour pouvoir faire une sauvegarde intermédiaire (quand il y en a le plus, c'est quand un conflit survient sur l'envoi d'un chemin modifié avec un conflit par noeud modifié par quelqu'un d'autre (mais ça dépasse rarement une vingtaine de conflits à résoudre pour fusionner et recontrôler le tout, sauvegarder à nouveau, avant d'envoyer la suite). Je me demande pourquoi JOSM par défaut essaye toujours de tout envoyer en une seule requête (ce qui complique ensuite les corrections en cas de problème en milieu d'un gros paquet). Mais il se trouve qu'ici justement je veais de réinstaller JOSM et que j'avais oublié de réduire la taille des requêtes. Une grosse transaction est partie mais je ne sais pas comment JOSM a récupéré une exception interne inattendue pour reprendre l'envoi sans rien dire et faire comme si de rien n'était, en envoyant à nouveau les objets à créer avec les mêmes ID négatifs sans lire la réponse du serveur lors du premier essai d'envoi ! La requête n'était pourtant pas si volumineuse, mais l'envoi a été inhabituellement long (je penche pour une rupture de session TCP entre chez moi et le serveur non rapportée par un routeur intermédiaire ou par le FAI, ou rapportée tardivement : en TCP il faut au moins 30 secondes minimum pour avoir au moins une erreur timeout en attente d'un ACK ou d'un NAK TCP, qui normalement ne prend que le temps du round-trip voisin de 20 ms si on le reçoit, multiplié par le nombre d'essais d'envoi des datagrammes non acquittés, ce qui prend alors au moins 3 minutes si la rupture de session TCP n'est pas rapportée au client ; bien plus long en fait que l'exécution de la requête que j'avais envoyée; sans doute le timeout est arrivé mais bien après). TCP est réputé "fiable" mais qui n'a jamais téléchargé un gros fichier ISO qui s'est avéré corrompu une fois qu'on l'utilise (alors qu'il se monte très bien ou peut être gravé sans erreur sur un DVD) ? Il y a bien la solution HTTPS mais le serveur actuellement ne semble l'utiliser que pour l'authentification et pas pour la signature sécurisée des transferts (je ne parle pas du cryptage ici mais d'un hachage sûr comme MD5 au minimum -- SHA1 préférable -- au sein même de la session HTTP ou bien au sein des transactions XML) : on envoie du XML brut, sans aucune clé de vérification par le serveur. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
