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;
+
