Retry logic of Quartz - java

Let me get straight to the question. I have two questions relating to the Quartz Scheduler working with a JDBC job store.
Suppose if my app crashes, I know that quartz will retry the jobs that should have been fired during the down time. What about the jobs that were getting executed at that point of time? And what about the failed retries which were happening? Would they also be handled?
What is this option? - org.quartz.jobStore.maxMisfiresToHandleAtATime in the properties file? Is it the maximum number of misfires that quartz will handle once it comes back up after say a crash?
Thanks in advance

Related

org.quartz.SchedulerException: The Scheduler has been shutdown in Magnolia

Schedule publishing is failing in magnolia due to below mentioned error. Scheduler is shutdown automatically and its leads to publishing failure.If I restart the author instance then scheduler is up and schedule publishing working fine.
What are the key actions which leads to shutdown the scheduler?
Is there any time frame set to scheduler ?
ERROR info.magnolia.task.schedule.DefaultTaskSchedulerService 30.10.2018 10:28:40 -- Could not schedule job [publish_9e827f8d-89f2-4c61-a0c5-bfe84d5c3a7e].
org.quartz.SchedulerException: The Scheduler has been shutdown.
at org.quartz.core.QuartzScheduler.validateState(QuartzScheduler.java:795)
at org.quartz.core.QuartzScheduler.scheduleJob(QuartzScheduler.java:846)
at org.quartz.impl.StdScheduler.scheduleJob(StdScheduler.java:249)
at info.magnolia.task.schedule.DefaultTaskSchedulerService.schedule(DefaultTaskSchedulerService.java:90)
at info.magnolia.task.DefaultTasksManager.scheduleTask(DefaultTasksManager.java:126)
at info.magnolia.module.workflow.jbpm.workitem.handler.ScheduleTaskWorkItemHandler.executeWorkItem(ScheduleTaskWorkItemHandler.java:49)
at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper$1.exec(WorkItemHandlerSystemContextWrapper.java:37)
at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper$1.exec(WorkItemHandlerSystemContextWrapper.java:33)
at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:400)
at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:378)
at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper.executeWorkItem(WorkItemHandlerSystemContextWrapper.java:33)
at org.drools.persistence.jcr.processinstance.JcrWorkItemManager.internalExecuteWorkItem(JcrWorkItemManager.java:76)
at org.jbpm.workflow.instance.node.WorkItemNodeInstance.internalTrigger(WorkItemNodeInstance.java:138)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerConnection(NodeInstanceImpl.java:381)
at org.jbpm.workflow.instance.node.SplitInstance.executeStrategy(SplitInstance.java:117)
at org.jbpm.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:63)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:325)
at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:73)
at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:44
> Blockquote
What are the key actions which leads to shutdown the scheduler?
The only action that can make it go down is user initiated shutdown.
Is there any time frame set to scheduler ?
No.
The only reasonable explanation seems to be programatically triggered shutdown.
Since this is not widely reported issue (personally I never heard about it before and I dare to say I've seen most of issues with Magnolia over last couple of years), I'd search your custom code or any community or 3rd party modules you have installed. Perhaps you can also create small scheduled task, e.g. over groovy and have it executed every minute. If the task is only to print the log statement, it should not add too much of the overhead to your instance but would allow you to better pinpoint time when shutdown happens (within minute after last log statement) and perhaps it can also help you find out the cause of shutdown.
Before doing this, you might also want to inspect log file for any exceptions happening prior to you detecting the shutdown, but I presume you have already done this.

Quartz Persistent Jobs mis-fire recovery using JDBC JobStore

I am implementing Quartz scheduler with JDBC JobStore in Spring. I have a use case, where if my application crashes and it has jobs to be executed within time frame between the crash and restart of the scheduler. My approach is to compare nextExecutionTime for all jobs with the current time at startup of the scheduler and if the nextExecutionTime is less than the current time, execute the job.
But I have a strong notion that there is a nicer way to get this job done. Either supported by Quartz or already implemented by someone. Can you suggest a better approach for this?
Does the misfire instruction feature do what you want? See the tutorial at Quartz Tutorial Lesson 4 and more specifically Example - Job Misfires You probably need to call withMisfireHandlingInstructionFireNow() when you build your trigger.

How to do "massive" Job Scheduling (Quartz?)

I have a general question related to the quartz scheduling framework:
I need to perform a task after a fixed amount of time after a user registration. For the sake of simplicity let's say exactly 1 hour after registration of a user in my system. The job MUST be done, even if the system is restarting during this one hour the task must be remembered and it MUST be performed later if my system is down at the usual time.
Is this something where I can or where I would use Quartz? I looked at persistent jobs which looks quite promising but I am not sure if this will still work out for 1000 jobs a day. Furthermore, I am not sure about the performance implications. Maybe someone can help me with information here.
If Quartz is not the right choice, which other ways/frameworks do you see for this issue? My application is a Java 6/Spring 3 based Web-App.
Thanks for your help!
We are using quartz persisted job store successfully in our production environment for a SaaS platform application where 100s of jobs are running.

How to make a specific scheduling job running from the time it is started?

I need to schedule a task that will perform the task at the given time by user. But this scheduling I need to run whether the application is running or not. So how could I specify the scheduling using quartz?
I am writing the code for the situation in servlet and then from where I need to run that servlet I am bit confused about it, because if I would use the load-on-startup it will call servlet every time the application is loaded so it will cause the job detail to be duplicated in data tables. And the scheduling will stop when user will logout the session. But I want the scheduling to be running till the tomcat is running.
Any help is appreciated. Thanks in advance.
To avoid duplication of the job in the database you can write your code to first check for the job before scheduling, or to first delete the job (whether or not it exists) before scheduling.
In 2.x API there is a checkExists() set of methods.

How to schedule multiple jobs in quartz scheduler using same trigger?

I am using quartz scheduler in my spring project. I have to run a job after another job which is scheduled to run in every 15 mins? I cant run this job concurrently as both of this jobs have to access same mail account using different protocols(one to send:smtp and other to receive: imap) and it may cause problems. Please reply quickly, as its an urgent requirement.
Just write a wrapper job class that launches second job after the first. You could then reuse separate jobs in the future if there will be any necessity.
You could do something with writing a job listener to recognize when the first job ends, and have it start the second. But the solution first suggested by mindas is easier - wrap both your jobs in another Job implementation, which is the one you actually schedule.

Categories

Resources