<div dir="ltr">Les échecs comme dans le message ci-dessus (erreur DNS du proxy pour joindre le serveur rails3 en upstream) ou des résultats incomplets/tronqués, concernent en gros 1 requête sur 3 à l'API (indépendamment de leur volume ou complexité), un des proxies est en panne, on tombe dessus au hasard, ou il est mal configuré dans le load-balancer.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 10 janv. 2020 à 06:05, Philippe Verdy <<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><img src="cid:ii_k57p5d8v0" alt="image.png" width="562" height="154"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 10 janv. 2020 à 05:59, Philippe Verdy <<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">je constate depuis aujourd'hui de très grosses lenteurs du serveur OSM pour presque tout, au chargement des données dans l'éditeur (même sous iD dans une toute petite zone, nombreux échecs, ou données partiellement chargées et tronquées, sous JOSM, des listes de membres de relation incomplètes ou des chemins longs auxquels manquent de nombreux points).<div>Lors de l'envoi, une partie des données est transmise, je passe mon temps à revérifier (donc recharger péniblement) et corriger ce qui n'est pas passé.</div><div>Et sous ID j'ai un message clair: ce sont les proxies qui retournent après de longs délais des erreurs 502 donnant une raison erreur DNS: problème de connexion avec le serveur central.</div><div>Cela semble être les proxies d'accès qui ont des problèmes, même si le serveur est fonctionnel.</div><div>De plus les minute diffs sont anormalement en retard (plus d'1/2 heure au moins quand les modifs sont habituellement visibles en 3 ou 4 minutes)</div><div><br></div><div>Mais maintenant c'est carrément la panne: plus moyen de faire quelque chose de fiable, même les vérifs après envoi mettent trop de temps ou se rechargent trop lentement et partiellement, jamais deux fois les mêmes résultats, d'où aussi l'apparition un peu partout de noeuds orphelins ou d'objets laissés en doublon (je pense que ça touche pas mal de monde avec les tentatives multiples de soumission à nouveau).</div><div><br></div><div>[[</div><div>Note: JOSM ne rapporte pas toutes les erreurs réseau, certaines sont encore totalement silencieuses (sauf si on a ouvert la console Java, ce qui n'est pas fait par défaut), méfiance car vous ne voyez pas forcément une boite d'alerte après une exception pourtant bien détectée durant le chargement ou l'envoi. Il est hautement recommandé de lancer JOSM avec la console ouverte.</div><div><br></div><div></div><div>Vérifiez votre panneau de configuration Java pour activer l'option console de journalisation, même si cela a pour effet d'ouvrir une fenêtre de plus qu'il ne faut pas fermer car on ne peut pas l'ouvrir à nouveau ensuite. Malheureusement JOSM n'inclue pas lui-même sa propre fenêtre console (ou l'inscription en backup vers un fichier log externe qu'on pourrait consulter à tout moment), on n'a que la fenêtre console du lanceur (fenêtre de commande dans laquelle on le lance via un shell, ou Javawebstart.</div><div><br></div><div>Cette option journal est bien pratique aussi pour gérer certains conflits d'édition ou erreurs lors d'un envoir et trouver les ID d'objets concernés, par fois de très grande liste qu'il faut garder en copie pour les inspecter ensuite un par un ou par lot. La console Java permet au moins de faire de copier-coller de ce qu'on veut garder.</div><div><br></div><div>Avec l'éditeur iD, on a besoin parfois aussi de la console Javascript du navigateur pour retrouver certaines erreurs non traitées par l'UI de l'appli web et en trouver la cause ou le détail car certains messages des serveurs ou proxies ne sont pas traitées: la console Javascript doit être ouverte sinon les logs ne sont pas gardés en mémoire, mais on peut toujours effacer la console à tout moment si on manque de mémoire et qu'on n'a rien à garder.</div><div>]]</div><div><br></div><div><div>Là aussi c'est indispensable en ce moment et révèle que ce n'est pas un problème de notre propre connexion internet jsqu'au front-end d'OSM, mais quelquepart entre le front-end/proxy et les serveurs, dans le réseau interne d'OSM. Et il semble que ce soit un problème de config DNS: les front-end proxies ont du mal à maintenir ou rouvrir les connexions au serveur, peut-etre une saturation mémoire ou d'un espace disque interne sur les proxies, ou une panne sur un routeur ou un switch interne, ou une panne chez Bytemark, l'hébergeur du domaine DNS <a href="http://osm.org" target="_blank">osm.org</a>.</div><div><br></div><div></div></div></div>
</blockquote></div>
</blockquote></div>