Si le RemoteControl a été activé dans les préférences de JOSM, le lancement de la seconde instance de JOSM ne pourra pas activer son propre RemoteControl sqns produire une erreur car le port TCP découte est déjà occupé par la première instance. De fait, JOSM devrait être capabme dans son module d'initialisation de tester si le port d'écoute RemoteControl est déjà occupé en tentant de l'allouer; s'il est déjà occupé il devrait alors essayer de s'y connecter pour lui envoyer une ligne de commande de chargement de données et sortir alors immédiatement en cas d'acceptation. La première instance prendra alors la ligne de commande pour créer un nouveau calque et charger les données demandées; ou simplement s'activer. En aucun cas on ne devrait avoir une seconde instance dès que RemoteControl est activé dans les préférences.
Cependnat dans certains cas, le port d'écoute est occupé mais ne répond pas à la requête. Il arrive parfois que c'est une première instance qui est resté "dans les choux" ou ne s'est pas encore terminée (j'ai déjà vu ça quand on change les préférences et qu'on les valide, pour que JOSM se relance (au redémarrage, le port n'est pas encore complètement libéré et l'initialisation de la nouvelle instance au redémarrage échoue justement à iniitialiser son port d'écoute pour RemoteControl; et on voit l(erreur dans la fenêtre de log). Cela semble ariver du fait que RemoteControl fait tourner son port d'écoute sur un thread séparé du thread principal: bien que la première instance soit théoriquement sortie, en fait seul son thread principal est terminé et se relance (c'est toujours la même insance de la machine virtuelle Java), mais le thread de Remote Control est resté encore actif sans encore sortir quand le nouveau thread principal s'initialiser pour relancer un thread pour RemoteControl... Quand on quitte JOSM; il semble d'ailleurs qu'il faille plusieurs secondes encore pour quele thread d'écoute de RemoteControl se termine (le temps que le GarbageCollector fasse son travail de nettoyage des threads en cours). Il peut arriver parfois que le délai avant que ce port d'écoute soit libéré prenne plus d'une minute car l'exécution de la commande "Quitter" dans JOSM semble oublier d'envoyer au Thread ReoteControl une commnde lui indiquant de se terminer proprement. D'ailleurs ce thread RemoteControl est particulièrement lent à répondre aux requêtes même dans une utilisation normale à distance depuis un navigateur. Presque à chaque fois le navigateur dignale une erreur de preise en charge de la requete, alors que la requête a bien été acceptée et prise en compte par RemoteControl. Le 30 octobre 2014 18:34, Pieren <pier...@gmail.com> a écrit : > 2014-10-30 18:19 GMT+01:00 Pierre-Yves Berrard < > pierre.yves.berr...@gmail.com>: > > > java -jar "D:\JOSM\josm-tested.jar" [--download=] P1070311.JPG > P1070312.JPG > > > > Mon problème est que si JOSM est déjà ouvert, une autre instance de > > l'éditeur est créée. > > Quelqu'un connaîtrait-il les options à ajouter pour empêcher ce > comportement > > ? > > Cette question serait plus pour la liste @dev-fr . Mais bon, sinon, > c'est normal que ta commande crée une nouvelle instance de josm. Si tu > veux controller une instance existante, il faudrait passer par le > remote control: > http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl > > Je pense que tu peux balancer les commandes depuis ton shell avec un > outil genre curl > > Pieren > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
