Package fr.ifremer.isisfish.simulator.launcher

package fr.ifremer.isisfish.simulator.launcher

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

archi

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.