Author |
Message |
|
It will depend how you "kill" the jvm, and how you configured Quartz. If Tomcat has a chance to to let Quartz shutdown, and there is a config to tell Quartz to wait for job to complete or not. If not, then it depend how you schedule the job to be durable/recoverable and what your misfired policy is. You can read more form the javadoc and guide for more.
|
|
|
Oh, I see what you asking.
Well, the "getTriggerState(name, group)" should return you trigger by name+group within your cluster since it hit the database.
Now the "getCurrentlyExecutingJobs()" is true that only give on the scheduler instance node, not the cluster. So, if you really want this, you can try write a JobListener that deploy to all your cluster node, and have it write to your own DB monitoring table for tracking. You can add record for "jobToBeExecuted" and remove record when "jobWasExecuted" is called.
|
|
|
Actually, the default "simpleSchedule()" is already set to firing only once. So you already doing it right.
Different trigger type has different scheduling (firing time) need. So if simple trigger scheduling satisfy your need, then it's a good choice already.
|
|
|
add "simpleSchedule().withRepeatCount(0)" will make it a one-time job.
|
|
|
Hello qwerty53,
Have you tried these?
http://quartz-scheduler.org/api/1.8.1/org/quartz/Scheduler.html#getCurrentlyExecutingJobs()
http://quartz-scheduler.org/api/1.8.1/org/quartz/Scheduler.html#getTriggerState(java.lang.String, java.lang.String)
|
|
|
How did you package your war file correctly? Did you have some old quartz jar loaded by accident?
QuartzInitializerServlet sure exists as part of the Quartz distribution. You may want to verify you have included properly in WEB-INF/lib of your war.
|
|
|
Is your job using DisallowConcurrentExecution? It's hard to tell without know what your job is doing. Quartz should have no problem starting your jobs per your cron schedule.
Also, I assume you are working your own Thread in your job, which is out of Quartz control. The thread pool quartz uses will auto execute your job and you can't assign it. However you can set your JobDetail with priority value and it will honor that though.
|
|
|
How are you updating the cron trigger? Try calling one of Scheduler method to replace the trigger. eg: rescheduleJob().
|
|
|
Can you try this setting?
Code:
<context-param>
<param-name>quartz:wait-on-shutdown</param-name>
<param-value>true</param-value>
</context-param>
Also, ensure none of your jobs are blocking the schedulers when it needs to shutdown.
What I observe is that even with this, the Tomcat server is picking about Thread used in context that is not shutdown fast enough. Sometimes we need to delay the webapp during servletcontext#detroy slightly just to avoid that WARNING. The WARNING is harmless if you can test scheduler is working and able to shutdown fully in command line mode.
|
|
|
Right, that's fine when Hibernate brings in new C3P0 version 0.9.1.2, which is what you want.
The Quartz does uses C3P0, however I don't see any API breakage when upgrade to 0.9.1.2. I can use C3P0 version 0.9.1.2 just fine with Quartz. What kinda of exact error do you have?
|
|
|
Ah, I see what you mean now. The Quartz API contract does not guarantee this either. However the listeners are already stored in a LinkedHashMap in scheduler, so use reverse order in jobWasExecuted calls should be easy to do, and it sounds like a reasonable request. You may want to create a JIRA feature request for this then.
|
|
|
Quartz execute the jobs as soon as it's time is due, and if you have multiple jobs that are due at exact time, then quartz place them in thread pool without order guarantee. As when it will complete, it also depends on your job implementations and your hardware speed.
So if you want the order enforced, you would need to control on your own. For example try store the job Id in order that's appear in jobToBeExecuted into a List and add it into the schedulerContext space, and then in jobWasExecuted, you may check for the reverse order. It's up to you what to do if they are out of order. You would have to be careful not to hold up the job threads though, or else you will have no room to execute any other jobs.
|
|
|
If you are using maven for your own app, then you may do this:
Code:
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
<version>2.2.0</version>
<exclusions>
<exclusion>
<groupId>c3p0</groupId>
<artifactId>c3p0</artifactId>
</exclusion>
</exclusions>
</dependency>
|
|
|
It's hard to tell. Is your job holding on to any open database connection and not ending? and I don't see your quartz config on DB pool config?
|
|
|
Maybe this article might help http://saltnlight5.blogspot.com/2013/08/how-to-configure-slf4j-with-different.html
|
|
|