Author: chatellier Date: 2009-02-16 08:43:48 +0000 (Mon, 16 Feb 2009) New Revision: 1814 Added: isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package-info.java isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/ssh/package-info.java Removed: isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package.html Log: Move documentation to package-info.java Added: isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package-info.java =================================================================== --- isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package-info.java (rev 0) +++ isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package-info.java 2009-02-16 08:43:48 UTC (rev 1814) @@ -0,0 +1,121 @@ +/** + * <h1>Launcher</h1> + * <h2>To do</h2> + * <li> voir pourquoi l'interface de visu des simulations en cours ne se + * rafraichi pas + * <li> supprimer le SimulationItem et tout mettre dans SimulationJob (reflechir + * si au niveau design c'est une bonne chose + * <li> faire une interface graphique de monitoring des Executors (nombre de + * threads actif, nombre de simulations terminer, nombre de simulation + * explicitement pour cet executor, afficher l'etat pause/resume/error et + * permettre de modifier l'etat. Avec le nombre + * de jobs dans la queue pour tous les Executors. Permettre de soumettre toutes + * les simulations d'un executor sur un autre executor. (par exemple si un + * executor est mis en pause a cause des erreurs, cela permet a l'utilisateur + * d'utiliser un autre executor sans devoir annuler/relancer toutes ces + * simulations. + * <li> ajouter dans l'interface de vision des simulations en cours, de + * modifier le launcher des simulations non lancee. + * <li> tester les differents launcher + * <li> trouver une solution pour que les jobs soumis pour un launcher + * particulier soit bien executer par l'executor de ce launcher. (penser au + * changement de priority avec resoumission si ce choix est pris, c-a-d que le + * job s'appercoit qu'il va etre utilise par le mauvais Executor, il ne fait + * pas la simu et la resoumet a queue en augmentant la priority pour que le job + * qui devait etre fait maintenant ne le soit pas dans 10ans). + * Une autre possibilite d'implantation est que chaque executor est une queue + * propre, et lorsque celle-ci est vide il vont piocher dans la queue commune. + * Pour cela, simplement implanter un nouveau type de queue qui permette + * d'avoir une queue mere. Lors de la soumission au SimulationService soit le + * job est directement soumis au bon executor soit ajoute a la queue general. + * (ajouter un bool qui permette lors de report d'erreur de resoumettre un job + * avec launcher fixe par l'utilisateur sur la queue general ou non. + * + * <h2>Architecture global</h2> + * <img src="doc-files/isis-simulation.png" alt="archi"/> + * + * <h2>Principe general</h2> + * <p> + * Les simulations sont soumises au {@link SimulationService} via sa methode + * submit. Un objet {@link SimulationJob} est alors cree et ajoute a la liste + * des simulations presentes ({@link SimulationService#getJobs}). Si la + * simulation est une simple simulation ou une simulation avec plan d'analyse + * dependant, elle est alors directement ajoutee a la queue de simulation + * (simulation a faire). Si + * la simulation utilise un plan d'analyse independant, un thread est + * specialement utilise pour generer toutes les simulations du plan, celles-ci + * sont alors ajoutee a la queue, mais n'apparaitront dans la liste des + * simulations qu'au moment ou un thread de simulation executera reellement le + * job. + * </p> + * + * <p> + * Lorsqu'un thread recupere un job dans la queue, il leve un event {@link + * SimulationListener#start}, la simulation est alors ajoutee a la liste des + * simulations visibles si elle ne l'etait pas encore. + * </p> + * + * <p> + * Une fois terminees, les simulations finissent dans la liste des simulations + * terminees. + * </p> + * + * <p> + * Le {@link SimulationService#autoLaunch} permet d'indique si le service est + * actif ou non. S'il n'est pas actif, il accepte les simulations mais ne les + * execute pas (elles sont en attente). S'il est actif alors les differents + * {@link SimulationExecutor}) prenent les jobs de la queue pour faire les + * simulations. + * </p> + * + * <h2>SimulationExecutor</h2> + * <p> + * Lors de sa creation le {@link SimulationService} a initialise different + * {@link SimulationExecutor} en fonction de la configuration. Ces {@link + * SimulationExecutor} sont responsable de l'execution des simulations de la + * queue. Chaque {@link SimulationExecutor} a un {@link SimulatorLauncher} + * qu'il utilise si la simulation n'a pas encore de {@link SimulatorLauncher} + * d'assigne. + * </p> + * <p> + * Un {@link SimulationExecutor} peut etre mis en pause puis relance. Lorsqu'il + * est en pause, il termine les simulations en cours mais n'en reprend pas de + * nouvelle. Cela permet d'arrete un {@link SimulationExecutor} particulier + * sans devoir arreter tout le service de simulation. + * </p> + * <p>Si un {@link SimulationExecutor} prend un job ayant deja un {@link + * SimulatorLauncher} d'assigne, il utilise alors ce launcher plutot que le + * sien. Ce choix est derangeant lorsque l'on souhaite utilise un nombre de + * thread limite pour un launcher particulier, mais il est le plus raisonnable + * car l'autre possibilite est que le job soit resoumis au {@link + * SimulationService} jusqu'a ce que le bon {@link SimulationExecutor} le + * prenne pour l'executer. On risque dans ce cas d'arriver a une forte + * consommation CPU si le seul {@link SimulationExecutor} disponible ne gere + * pas les jobs en queue. + * </p> + * + * <h2>SimulationJob</h2> + * + * <p> + * Le simulation Job encapsule l'appel pour que les implantantations des {@link + * SimulatorLauncher} soit la plus simple possible. Il gere les simulations + * avec plan dependant, les exports depandes par l'utilisateur, ainsi que + * l'effacement des simulations si seul les exports interessait l'utilisateur. + * </p> + * + * <p> + * Si le job n'arrive pas a utilise le {@link SimulatorLauncher} il en notifie + * le {@link SimulationService} qui resoumet le job dans la queue pour qu'un + * autre {@link SimulationExecutor} prenne ce job. Si trop d'erreurs sont + * notifiees pour un meme {@link SimulatorLauncher}, le {@link + * SimulatorService} prend alors la decision d'arreter l'executor associe. + * </p> + * <p> + * Pour les simulations ou l'utilisateur avait fixe un {@link + * SimulatorLauncher} particulier en cas de notification d'erreur au {@link + * SimulationService} ce {@link SimulatorLauncher} n'est plus pris en compte et + * n'importe quel {@link SimulatorLauncher} peut faire cette simulation. + * </p> + */ +package fr.ifremer.isisfish.simulator.launcher; + Deleted: isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package.html =================================================================== --- isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package.html 2009-02-14 13:58:57 UTC (rev 1813) +++ isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/package.html 2009-02-16 08:43:48 UTC (rev 1814) @@ -1,122 +0,0 @@ -<html> - <body> - <h1>Launcher</h1> - -<h2>To do</h2> -<li> voir pourquoi l'interface de visu des simulations en cours ne se -rafraichi pas -<li> supprimer le SimulationItem et tout mettre dans SimulationJob (reflechir -si au niveau design c'est une bonne chose -<li> faire une interface graphique de monitoring des Executors (nombre de -threads actif, nombre de simulations terminer, nombre de simulation -explicitement pour cet executor, afficher l'etat pause/resume/error et -permettre de modifier l'etat. Avec le nombre -de jobs dans la queue pour tous les Executors. Permettre de soumettre toutes -les simulations d'un executor sur un autre executor. (par exemple si un -executor est mis en pause a cause des erreurs, cela permet a l'utilisateur -d'utiliser un autre executor sans devoir annuler/relancer toutes ces -simulations. -<li> ajouter dans l'interface de vision des simulations en cours, de -modifier le launcher des simulations non lancee. -<li> tester les differents launcher -<li> trouver une solution pour que les jobs soumis pour un launcher -particulier soit bien executer par l'executor de ce launcher. (penser au -changement de priority avec resoumission si ce choix est pris, c-a-d que le -job s'appercoit qu'il va etre utilise par le mauvais Executor, il ne fait -pas la simu et la resoumet a queue en augmentant la priority pour que le job -qui devait etre fait maintenant ne le soit pas dans 10ans). -Une autre possibilite d'implantation est que chaque executor est une queue -propre, et lorsque celle-ci est vide il vont piocher dans la queue commune. -Pour cela, simplement implanter un nouveau type de queue qui permette -d'avoir une queue mere. Lors de la soumission au SimulationService soit le -job est directement soumis au bon executor soit ajoute a la queue general. -(ajouter un bool qui permette lors de report d'erreur de resoumettre un job -avec launcher fixe par l'utilisateur sur la queue general ou non. - -<h2>Architecture global</h2> -<img src="doc-files/isis-simulation.png" alt="archi"/> - -<h2>Principe general</h2> -<p> -Les simulations sont soumises au {@link SimulationService} via sa methode -submit. Un objet {@link SimulationJob} est alors cree et ajoute a la liste -des simulations presentes ({@link SimulationService#getJobs}). Si la -simulation est une simple simulation ou une simulation avec plan d'analyse -dependant, elle est alors directement ajoutee a la queue de simulation -(simulation a faire). Si -la simulation utilise un plan d'analyse independant, un thread est -specialement utilise pour generer toutes les simulations du plan, celles-ci -sont alors ajoutee a la queue, mais n'apparaitront dans la liste des -simulations qu'au moment ou un thread de simulation executera reellement le -job. -</p> - -<p> -Lorsqu'un thread recupere un job dans la queue, il leve un event {@link -SimulationListener#start}, la simulation est alors ajoutee a la liste des -simulations visibles si elle ne l'etait pas encore. -</p> - -<p> -Une fois terminees, les simulations finissent dans la liste des simulations -terminees. -</p> - -<p> -Le {@link SimulationService#autoLaunch} permet d'indique si le service est -actif ou non. S'il n'est pas actif, il accepte les simulations mais ne les -execute pas (elles sont en attente). S'il est actif alors les differents -{@link SimulationExecutor}) prenent les jobs de la queue pour faire les -simulations. -</p> - -<h2>SimulationExecutor</h2> -<p> -Lors de sa creation le {@link SimulationService} a initialise different -{@link SimulationExecutor} en fonction de la configuration. Ces {@link -SimulationExecutor} sont responsable de l'execution des simulations de la -queue. Chaque {@link SimulationExecutor} a un {@link SimulatorLauncher} -qu'il utilise si la simulation n'a pas encore de {@link SimulatorLauncher} -d'assigne. -</p> -<p> -Un {@link SimulationExecutor} peut etre mis en pause puis relance. Lorsqu'il -est en pause, il termine les simulations en cours mais n'en reprend pas de -nouvelle. Cela permet d'arrete un {@link SimulationExecutor} particulier -sans devoir arreter tout le service de simulation. -</p> -<p>Si un {@link SimulationExecutor} prend un job ayant deja un {@link -SimulatorLauncher} d'assigne, il utilise alors ce launcher plutot que le -sien. Ce choix est derangeant lorsque l'on souhaite utilise un nombre de -thread limite pour un launcher particulier, mais il est le plus raisonnable -car l'autre possibilite est que le job soit resoumis au {@link -SimulationService} jusqu'a ce que le bon {@link SimulationExecutor} le -prenne pour l'executer. On risque dans ce cas d'arriver a une forte -consommation CPU si le seul {@link SimulationExecutor} disponible ne gere -pas les jobs en queue. -</p> - -<h2>SimulationJob</h2> - -<p> -Le simulation Job encapsule l'appel pour que les implantantations des {@link -SimulatorLauncher} soit la plus simple possible. Il gere les simulations -avec plan dependant, les exports depandes par l'utilisateur, ainsi que -l'effacement des simulations si seul les exports interessait l'utilisateur. -</p> - -<p> -Si le job n'arrive pas a utilise le {@link SimulatorLauncher} il en notifie -le {@link SimulationService} qui resoumet le job dans la queue pour qu'un -autre {@link SimulationExecutor} prenne ce job. Si trop d'erreurs sont -notifiees pour un meme {@link SimulatorLauncher}, le {@link -SimulatorService} prend alors la decision d'arreter l'executor associe. -</p> -<p> -Pour les simulations ou l'utilisateur avait fixe un {@link -SimulatorLauncher} particulier en cas de notification d'erreur au {@link -SimulationService} ce {@link SimulatorLauncher} n'est plus pris en compte et -n'importe quel {@link SimulatorLauncher} peut faire cette simulation. -</p> -</body> -</html> \ No newline at end of file Added: isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/ssh/package-info.java =================================================================== --- isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/ssh/package-info.java (rev 0) +++ isis-fish/trunk/src/main/java/fr/ifremer/isisfish/simulator/launcher/ssh/package-info.java 2009-02-16 08:43:48 UTC (rev 1814) @@ -0,0 +1,8 @@ +/** + * SSH utility class for {@link SSHSimulatorLauncher}. + * + * Part of this code has been taken from + * Ant optional tasks. + */ +package fr.ifremer.isisfish.simulator.launcher.ssh; +