[jira] [Commented] (DELTASPIKE-1449) Broken quartz annotations and duplicate job details
[
https://issues.apache.org/jira/browse/DELTASPIKE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714566#comment-17714566
]
Gary Hodgson commented on DELTASPIKE-1449:
--
Hi, we just hit the quartz annotations part of this bug after updating from
1.9.0 to 1.9.6.
As Michel states it was introduced in
https://github.com/apache/deltaspike/pull/84, if I understand the code
correctly, with the introduction of the
[JobAdapter|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/JobAdapter.java]
class.
This is used by the default org.apache.deltaspike.scheduler.spi.Scheduler:
[JobQuartzScheduler|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/JobQuartzScheduler.java]
for the FinalJobClass which in turn the
[AbstractQuartzScheduler|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L192]
uses to specify the JobClass in JobDetail.
[org.quartz.impl.JobDetailImpl#isConcurrentExectionDisallowed|https://github.com/quartz-scheduler/quartz/blob/quartz-2.3.x/quartz-core/src/main/java/org/quartz/impl/JobDetailImpl.java#L386]
then looks for the DisallowConcurrentExecution annotation on the jobClass to
determine if concurrent exection is disallowed:
{code:java}
public boolean isConcurrentExectionDisallowed() {
return ClassUtils.isAnnotationPresent(jobClass,
DisallowConcurrentExecution.class);
}
{code}
So far I can't see the use of the JobAdapter class at all, and when I created a
simple test JobQuartzScheduler which returns the original class name:
{code:java}
public class MyJobQuartzScheduler extends AbstractQuartzScheduler {
...
@Override
protected Class createFinalJobClass(Class
jobClass) {
return jobClass;
}
{code}
the annotations are found and the regression is gone.
> Broken quartz annotations and duplicate job details
> ---
>
> Key: DELTASPIKE-1449
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1449
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Scheduler
>Affects Versions: 1.9.1
>Reporter: Michel Zedler
>Priority: Major
>
> This exemplary job class
> {code:java}
> package my.package
> import org.apache.deltaspike.scheduler.api.Scheduled;
> import org.quartz.DisallowConcurrentExecution;
> import org.quartz.Job;
> @Scheduled(cronExpression = "...", overrideOnStartup = true)
> @DisallowConcurrentExecution
> public class MyJob implements Job {
> ...
> } {code}
> using deltaspike 1.9.0 results in:
> {noformat}
> table: QRTZ_JOB_DETAILS
> row 1:
> JOB_NAME = MyJob
> JOB_CLASS_NAME = my.package.MyJob
> IS_NONCONCURRENT = 1 (true){noformat}
> using deltaspike 1.9.1 or later
> + a previously empty table results in:
> {noformat}
> table: QRTZ_JOB_DETAILS
> row 1:
> JOB_NAME = my.package.MyJob
> JOB_CLASS_NAME = org.apache.deltaspike.scheduler.impl.JobAdapter
> IS_NONCONCURRENT = 0 (false){noformat}
> + a non-empty table results in:
> {noformat}
> table: QRTZ_JOB_DETAILS
> row 1: (inserted by a deployment using 1.9.0 or earlier)
> JOB_NAME = MyJob
> JOB_CLASS_NAME = my.package.MyJob
> IS_NONCONCURRENT = 1 (true)
> row 2:
> JOB_NAME = my.package.MyJob
> JOB_CLASS_NAME = org.apache.deltaspike.scheduler.impl.JobAdapter
> IS_NONCONCURRENT = 0 (false){noformat}
>
> I tracked this behaviour down to changes by DELTASPIKE-1369 that were
> released with 1.9.1
> causing:
> (1) annotations org.quartz.DisallowConcurrentExecution and
> org.quartz.PersistJobDataAfterExecution to be effectively ignored because
> Quartz checks for their presence in class
> org.apache.deltaspike.scheduler.impl.JobAdapter.
> (2) consecutive deployments to produce duplicate job details.
> I could not find any release notes, migration guides or open bugs or fixes
> concerning this topic.
> Expected behaviour:
> * deltaspike/quartz should update existing JobDetails instead of inserting
> duplicates
> (JOB_CLASS_NAME of existing job details can be matched to new JOB_NAME - both
> are the fully qualified class name)
> * functionality of quartz annotations should be restored
> I can provide more context if useful.
> Are there any known workarounds?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1396) Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Hodgson updated DELTASPIKE-1396: - Description: The AbstractQuartzScheduler.stop method calls the shutdown method of the Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) However the parameter is called waitForJobsToComplete * @param waitForJobsToComplete * if true the scheduler will not allow this method * to return until all currently executing jobs have completed. which means the config actually does the opposite of what it intends, i.e. deltaspike.scheduler.force_stop=true would actually wait for the executing jobs to complete rather than stopping immediately. I presume this would be fixed by negating the parameter: this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); Mailing List Thread: [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] was: The stop method calls the shutdown method of the Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) However the parameter is called waitForJobsToComplete * @param waitForJobsToComplete * if true the scheduler will not allow this method * to return until all currently executing jobs have completed. which means the config actually does the opposite of what it intends, i.e. deltaspike.scheduler.force_stop=true would actually wait for the executing jobs to complete rather than stopping immediately. I presume this would be fixed by negating the parameter: this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); Mailing List Thread: [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] > Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler > Module > --- > > Key: DELTASPIKE-1396 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1396 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Gary Hodgson >Priority: Major > > The AbstractQuartzScheduler.stop method calls the shutdown method of the > Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": > > this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) > However the parameter is called waitForJobsToComplete > * @param waitForJobsToComplete > * if true the scheduler will not allow this method > * to return until all currently executing jobs have completed. > which means the config actually does the opposite of what it intends, i.e. > deltaspike.scheduler.force_stop=true would actually wait for the executing > jobs to complete rather than stopping immediately. > I presume this would be fixed by negating the parameter: > > this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > Mailing List Thread: > [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DELTASPIKE-1396) Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler Module
[ https://issues.apache.org/jira/browse/DELTASPIKE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Hodgson updated DELTASPIKE-1396: - Summary: Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler Module (was: Potential discrepancy in AbstractQuartzScheduler.stop of Scheduler Module) > Incorrect parameter meaning in AbstractQuartzScheduler.stop of Scheduler > Module > --- > > Key: DELTASPIKE-1396 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1396 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Gary Hodgson >Priority: Major > > The stop method calls the shutdown method of the Quartz scheduler with the > base config of "deltaspike.scheduler.force_stop": > > this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) > However the parameter is called waitForJobsToComplete > * @param waitForJobsToComplete > * if true the scheduler will not allow this method > * to return until all currently executing jobs have completed. > which means the config actually does the opposite of what it intends, i.e. > deltaspike.scheduler.force_stop=true would actually wait for the executing > jobs to complete rather than stopping immediately. > I presume this would be fixed by negating the parameter: > > this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); > > Mailing List Thread: > [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DELTASPIKE-1396) Potential discrepancy in AbstractQuartzScheduler.stop of Scheduler Module
Gary Hodgson created DELTASPIKE-1396: Summary: Potential discrepancy in AbstractQuartzScheduler.stop of Scheduler Module Key: DELTASPIKE-1396 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1396 Project: DeltaSpike Issue Type: Bug Security Level: public (Regular issues) Reporter: Gary Hodgson The stop method calls the shutdown method of the Quartz scheduler with the base config of "deltaspike.scheduler.force_stop": this.scheduler.shutdown(SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); ([https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L161]) However the parameter is called waitForJobsToComplete * @param waitForJobsToComplete * if true the scheduler will not allow this method * to return until all currently executing jobs have completed. which means the config actually does the opposite of what it intends, i.e. deltaspike.scheduler.force_stop=true would actually wait for the executing jobs to complete rather than stopping immediately. I presume this would be fixed by negating the parameter: this.scheduler.shutdown(!SchedulerBaseConfig.LifecycleIntegration.FORCE_STOP); Mailing List Thread: [https://lists.apache.org/thread.html/366d51433ea5c5deb7e1d83e09891e426bff9cae0eb6bff98990eb40@%3Cusers.deltaspike.apache.org%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
