Interface Summary
Interface	Description
SimulationJob.PostAction	Interface permettant d'implanter des actions a faire apres la simulation.
SimulationServiceListener	Ecouteur sur les evenenements de changement d'états des simulations.
SimulationServiceTableModel.AbstractJobListener
SimulatorLauncher	Interface devant etre implantée par les classes souhaitants etre utilisees comme plugin de simulation (InProcess, SubProcess, Datarmor, ...)

Class Summary
Class	Description
InProcessSimulatorLauncher	Fait une simulation dans la meme jvm.
InProcessSimulatorLauncher.ObjectCreationListener
JDKPriorityBlockingQueue<E>	It's based on PriorityBlockingQueue code, because PriorityBlockingQueue use private field for ReentrantLock :(
OptimizationPrepareJob	Permet de generer l'enchainement des simulations d'optimisation.
SimulationExecutor	Un executor qui utilise un certain type de `SimulatorLauncher` pour executer les jobs soumis dans la queue de `SimulationService` Les fonctionnalites en plus par rapport a un `ThreadPoolExecutor` sont: la possibilite de suspendre l'executor puis ensuite de le relancer l'utilisation de beforeExecute pour fixer le `SimulatorLauncher` du job Il est aussi possible d'ecoute l'etat de l'attribut pause
SimulationItem	Objet representant une simulation qui doit être faite.
SimulationJob	Classe responsable de la simulation d'un `SimulationItem`.
SimulationMonitor	Moniteur singleton pour pouvoir sauvegarder localement la liste des simulations démarrées et permettre de continuer le monitoring au relancemenent d'Isis.
SimulationPlanPrepareJob	Permet de genere les sous simulations d'un plan de simulation.
SimulationQueue	Multi tail PriorityBlockingQueue.
SimulationService	Cette classe est responsable de conservation de toutes les simulations faites ou a faire.
SimulationServiceTableModel	Model de table pour suivre l'evolution des differentes simulations en cours.
SSHSimulatorLauncher	Use a remote simulation server.
SSHSimulatorLauncher.ControlProgressMonitor	Redefine a custom progress monitor that update control.
SubProcessSimulationLauncher	Lanceur de simulation dans un sous processus.

Package fr.ifremer.isisfish.simulator.launcher Description

Isis fish simulation launchers.

To do

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.
ajouter dans l'interface de vision des simulations en cours, de modifier le launcher des simulations non lancee.
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.

Architecture global

Principe general

Les simulations sont soumises au SimulationService via sa methode submit. Un objet SimulationJob est alors cree et ajoute a la liste des simulations presentes (SimulationService.getJobs()). Si la simulation est une simple simulation ou une simulation avec plan de simulation dependant, elle est alors directement ajoutee a la queue de simulation (simulation a faire). Si la simulation utilise un plan de simulation 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.

Lorsqu'un thread recupere un job dans la queue, il leve un event SimulationServiceListener.simulationStart(SimulationService, SimulationJob), la simulation est alors ajoutee a la liste des simulations visibles si elle ne l'etait pas encore.

Une fois terminees, les simulations finissent dans la liste des simulations terminees.

Le 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 SimulationExecutor) prenent les jobs de la queue pour faire les simulations.

SimulationExecutor

Lors de sa creation le SimulationService a initialise different SimulationExecutor en fonction de la configuration. Ces SimulationExecutor sont responsable de l'execution des simulations de la queue. Chaque SimulationExecutor a un SimulatorLauncher qu'il utilise si la simulation n'a pas encore de SimulatorLauncher d'assigne.

Un 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 SimulationExecutor particulier sans devoir arreter tout le service de simulation.

Si un SimulationExecutor prend un job ayant deja un 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 SimulationService jusqu'a ce que le bon SimulationExecutor le prenne pour l'executer. On risque dans ce cas d'arriver a une forte consommation CPU si le seul SimulationExecutor disponible ne gere pas les jobs en queue.

SimulationJob

Le simulation Job encapsule l'appel pour que les implantantations des 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.

Si le job n'arrive pas a utilise le SimulatorLauncher il en notifie le SimulationService qui resoumet le job dans la queue pour qu'un autre SimulationExecutor prenne ce job. Si trop d'erreurs sont notifiees pour un meme SimulatorLauncher, le SimulationService prend alors la decision d'arreter l'executor associe.

Pour les simulations ou l'utilisateur avait fixe un SimulatorLauncher particulier en cas de notification d'erreur au SimulationService ce SimulatorLauncher n'est plus pris en compte et n'importe quel SimulatorLauncher peut faire cette simulation.