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.
Related
We need to monitor the status of quartz jobs by only having access to the database. Does quartz offer a way to achieve this?
Reading the documentation, in the Trigger class we have TriggerState which defines various states, ERROR and COMPLETE among others.
But during regular execution, the CompleteExecutionInstruction is always NOOP. It doesn't matter if I throw an exception or execute completely. I was expecting something like COMPLETE if I was successful or ERROR if I threw an exception.
Does anyone have any experience with this?
Trigger state in no way reflects the last execution status of your job so you cannot expect the trigger state to be COMPLETE or ERROR.
If you want to monitor your jobs, I recommend that you look into the Quartz JobListener interface. This interface allows you to intercept and process all job execution events that you may be interested in. For example, you may want to implement a job listener that stores the intercepted job execution events in a database and then you can query this database to obtain the last job execution status of your jobs etc.
You may also consider using an existing Quartz scheduler, job and trigger management and monitoring tool. I am the original author of QuartzDesk which is one of these tools. QuartzDesk is a completely non-intrusive tool that does not require you to modify your application code in any way, and it can work with all types of Java applications and nearly all Quartz versions. There is a public online demo that you can register to, try and see for yourself if the tool satisfies your requirements. When it comes to monitoring, the QuartzDesk GUI displays a so-called health indicator next to each job and trigger. This indicator depicts the status (success, error, veto) of the last 10 job/trigger executions so you can quickly see if there are any jobs that failed recently etc. You can also access complete execution history of individual jobs and trigger. If you want to be notified of any job execution related event, you can create an execution notification rule that will send you a notification message (IM, SMS, email, Slack, HipChat, SNMP Trap, ...) when a configured condition is met. I am attaching a screenshot of the GUI showing job health indicators and the selected job's execution history.
.
Say my web app has two spring cron jobs scheduled to run every minute/hour. Before I'm redeploying my app I can't just shut it down, I must wait for jobs to be finished correctly. I can provide some flag in database or somewhere else, so that jobs will stop to run iteratively - every minute or hour - put some check inside job function to return/do nothing on the next trigger call if such flag checked.
But how can I wait for current job call to finish? And how to see it from ant or other outside script - to choose good time for server shutdown.
There may be solution to put some flag in db or file, and read it. But may be there is some more accurate way - jms or something like that?
Instead of using the database you can use JMX. -- But in my humble opinion: If you already use a database but no JMX yet, then use a DB flag, or a simple file, to signal the timer to "stop".
More nice than using the flag and check for every invocation if the flag is set would be shoting shutdown() down the ThreadPoolTaskSchedule or ThreadPoolTaskExecutor.
But this would require a second task (run every minute or shorter) to check the flag and then shutdown to scheduler.
To make the ant task wait for a timespan, after setting the flag, to make sure that the last task is done, you can use the WaitFor task.
If you're using a TaskExecutor to run the "cron" jobs, then you could use the method described by skaffman in this answer to get the results of the task execution. If you need access to this from ant, you could probably use spring's JMS support with ant-jms.
What happens when a job does not run because of the disallow annotation.
Is it queued to run after the currently running instance dies?
Is that duplicate "run" of it just thrown away, never to be heard from again?
I've tried testing in code, but my inexperience with the language and library is causing some difficulty.
The additional firings are just delayed (as if no worker thread is available to run them) until the first instance completes. If that causes the next fire time to be missed by more than the scheduler's configured misfire threshold, then the misfire instruction will be applied to the trigger that was blocked.
I'm not exactly sure -- but I think this is equivalent to setting the "synchronized" keyword, which means, the duplicate run will happen after the current running instance dies.
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.
I have a requirement in which I have to do a certain database relted activity when my Quartz will be shut down. I mean I have to wipe out a certain data from the database when I shutdown the scheduler. Is there any way I can achieve this?
While googling I came across methods to determine the present state of the scheduler. But, is there a way I can capture this scheduler shutdown event.
Thanks in Advance,
Ibu
Can you add a ScheduleListener and watch for calls on schedulerShutdown() ?
e.g. Implement an instance of ScheduleListener (which would probably only do something for the implementation of schedulerShutdown().
Then add it to your scheduler instance using Scheduler.addSchedulerListener(). That way your instance of SchedulerListener should get a callback when the scheduler shuts down.
This assumes the scheduler shuts down cleanly. You may have to add a Runtime shutdownHook to ask the scheduler to shutdown.