Quartz et getCurrentlyExecutingJobs

Bonjour,

Nous avons utilisé au sein d'une application J2EE, l'api QUARTZ qui permet de lancer des traitements plus ou moins long.

Je voudrais mettre en place une lecture de la liste des Jobs lancés par QUARTZ, afin d'évaluer le nombre de jobs et de gérer ces jobs (Arrêter, résumer ...)

A la lecture des docs, des APIs que j'ai pu trouver sur la toile, il y a un élément nommé JobStore qui permet de faire cela avec une extension qui est RAMJobStore pour les avoirs en mémoire directement (à ce que j'ai compris).

Cependant malgré toute la bonne volonté du monde, je n'arrive pas à trouver un exemple concret du fonctionnement de JobStore et comment je peux récupérer la liste de mes jobs en cours d'exécution ... un sample simple ... Ou il y a peut-être d'autre solution ?

Merci d'avance de votre réponse.

Michael.

Je pense que tu as besoin d'utiliser Scheduler plutôt (cf: http://www.opensymphony.com/quartz/a...Scheduler.html)

Alors tout à fait, j'avais commencé par essayer cette solution.

Code:

---

1 2 3 4 5 6 7 8 9

// Récupération de la factory pour du scheduler StdSchedulerFactory factory = (StdSchedulerFactory) this.servlet.getServletContext().getAttribute(QuartzInitializerServlet.QUARTZ_FACTORY_KEY);   Scheduler sch = factory.getScheduler();   // List getCurrentlyExecutingJobs() //Return a list of JobExecutionContext objects that represent all currently executing Jobs in this Scheduler instance. List info = sch.getCurrentlyExecutingJobs();

---

Mais la variable info est vide ... et je ne vois pas pourquoi, et mon job est bien en cours ...

Ça n'est pas normal je pense, on peux voir comment tu crée tes jobs et comment tu lance quartz?

Je lance, via mon web.xml quartz :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<context-param> <param-name>shutdown-on-unload</param-name> <param-value>true</param-value> </context-param>   <context-param> <param-name>start-scheduler-on-load</param-name> <param-value>true</param-value> </context-param>   <listener> <listener-class>org.quartz.ee.servlet.QuartzInitializerListener</listener-class> </listener>

---

Le fichier quartz.properties :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

#========================================================= # Configure Main Scheduler Properties #=========================================================   org.quartz.scheduler.instanceName = sinWebScheduler org.quartz.scheduler.instanceId = 1 org.quartz.scheduler.rmi.export = false org.quartz.scheduler.rmi.proxy = false   #========================================================= # Configure ThreadPool #=========================================================   org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 5 org.quartz.threadPool.threadPriority = 5   #========================================================= # Configure JobStore #=========================================================   org.quartz.jobStore.misfireThreshold = 60000 org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

---

puis je lance un job, comme suit dans une Action Strust :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

// Récupération de la factory pour du scheduler StdSchedulerFactory factory = (StdSchedulerFactory) this.servlet.getServletContext().getAttribute(QuartzInitializerServlet.QUARTZ_FACTORY_KEY);   Scheduler sch = factory.getScheduler(); request.setAttribute("scheduler", sch);   // Création d'un nom de job pour les forfaits. String nameJob = "job"+user.getUid().toLowerCase()+"impFft";   //Création du job JobDetail jobDetail = new JobDetail(nameJob, Scheduler.DEFAULT_GROUP, ImportForfaitJob.class); jobDetail.setJobDataMap(map); jobDetail.setDurability(true); // Permet de rester dans la file afin qu'il soit supprimer manuellement jobDetail.setVolatility(true); // N'est pas conserver après reboot du serveur web. sch.addJob(jobDetail, true); // Ajout du job dans le scheduler   // Exécution du job SimpleTrigger trigger = null; try { trigger = new SimpleTrigger("trt"+user.getUid().toLowerCase()+"impFft", Scheduler.DEFAULT_GROUP); trigger.setJobName(jobDetail.getName()); sch.scheduleJob(trigger); } catch (org.quartz.ObjectAlreadyExistsException e) { log.debug("InitialiserCycleAction le job est déjà là: ", e); }

---

Est ce que j'ai oublié qqchose ?

Non, personnellement je ne vois pas, et si tu fais getCurrentlyExecutingJobs() avec la même instance de Scheduler, juste après avoir ajouté ton job ça ne fonctionne pas?

Le seul soucis qui peux arriver c'est que la StdSchedulerFactory te génère un nouveau Scheduler et qu'il n'ait pas accès aux précédents jobs...

Perso j'utilise la même instance en faisant un lookup JNDI en cas de besoin.

Je te confirme que le getCurrentlyExecutingJobs() fonctionne correctement avec le scheduler lorsque c'est le même scheduler.

Ceci ne m'arrange pas ... Hélas :cry:

J'utilise une factory, OK, cependant je peux quand même retrouver la liste des listeners qui sont en cours ? Lorsque j'utilise getAllSchedulers() sur la factory, il me rend bien cette fois mon sinWebScheduler, mais comment récupérer les informations du scheduler "sinWebScheduler" ?

Pour ta proposition - Est ce que tu peux m'expliquer ce que tu veux dire là ?

Citation:

---

un lookup JNDI en cas de besoin

---

tu devrais stocker le scheduler, plutot que la factory dans le context.

Ensuite, une fois que tu as un scheduler, il faut faire getJobGroupNames() pour avoir la liste des groupes. Pour chaque groupe, il faut faire getJobNames() pour avoir la liste des jobid, et ensuite, il faut faire avec group + jobid, getJobDetail().


Le CurrentlyExecutingJob te retourne exactement ce qui est marqué dans la doc: la liste des jobs en cours d'exécution. Les jobs en attente et les jobs fini n'y apparaissent pas.

Citation:

---

Envoyé par Hecco

Je te confirme que le getCurrentlyExecutingJobs() fonctionne correctement avec le scheduler lorsque c'est le même scheduler.

Ceci ne m'arrange pas ... Hélas :cry:

J'utilise une factory, OK, cependant je peux quand même retrouver la liste des listeners qui sont en cours ? Lorsque j'utilise getAllSchedulers() sur la factory, il me rend bien cette fois mon sinWebScheduler, mais comment récupérer les informations du scheduler "sinWebScheduler" ?

Pour ta proposition - Est ce que tu peux m'expliquer ce que tu veux dire là ?

---

J'utilise le JBoss MBean, il s'occupe de mettre le Scheduler dans le JNDI. Tu peux l'utiliser si ton server possède un mechanisme de bean qui se chargent au démarrage ou l'implémenter toi-même:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

InitialContext rootCtx = null; try { rootCtx = new InitialContext(); Name fullName = rootCtx.getNameParser("").parse(jndiName); Scheduler scheduler = schedulerFactory.getScheduler(); NonSerializableFactory.rebind(fullName, scheduler, true); } finally { if (rootCtx != null) { try { rootCtx.close(); } catch (NamingException JavaDoc ignore) {} } }

---

Ton scheduler est ensuite accessible via:

Code:

---

1 2 3 4 5 6 7

Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); env.put(Context.PROVIDER_URL, "jnp://localhost:1099"); env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); InitialContext ctx = new InitialContext(env); Scheduler sched = (Scheduler) ctx.lookup(jndiName);

---

Bonjour,

Merci à vous deux pour vos réponses, je notes ta méthode yciabaud, qui me parait interessante à garder en mémoire.

J'ai donc réussi à lire mes jobs en exécution avec le getCurrentlyExecutingJobs, cependant, à la place de mettre : factory.getScheduler(), j'ai précisé mon scheduler comme ci-dessous.

Code:

---

1 2 3 4 5 6 7 8

// Récupération de la factory pour du scheduler StdSchedulerFactory factory = (StdSchedulerFactory) this.servlet.getServletContext().getAttribute(QuartzInitializerServlet.QUARTZ_FACTORY_KEY);   //Collection info = factory.getScheduler(); Scheduler sch = factory.getScheduler("sinWebScheduler");   List info = sch.getCurrentlyExecutingJobs();

---

Dans mon application, certain de mes traitements utilisent du RMI pour envoyer des traitements à un autre listener QUARTZ. Ainsi, en revenant sur un cas de base, je me suis donc apercu que je n'interrogeais pas le bon listener quartz, car oui j'ai les 2 cas ... Cas avec RMI, ou cas de lancement de traitements sur le serveur.

En tout cas merci de votre aide et de vos réponses, ceci m'a permis de me débloquer.

Michael.