Closed vondacho closed 1 month ago
/cc @manovotn (scheduler), @mkouba (scheduler)
basically the need is to use quartz for some jobs, while keeping the normal local scheduler for all others. it would be nice to have a specific annotation QuartzScheduled to specifically mark some jobs as run by quartz, while all others would still be run through the default local non persistent scheduler. we use quartz for the specific jobs that need to be clustered. and we do not want all other normal @Scheduled jobs to start running through quartz (and even less in a clustered aware situation) just because we added the the quartz extension. If I compare with JobRunr, we can see that they opted for a dedicated annotation. would that be an option for the quartz extension? or is there a way to force the other @Scheduled methods to run local (ie: not run in a clustered aware setup)?
I would think a clustered=false added to the @Schedule annotation would be more elegant no?
That's an interesting use case. To be clear - this only applies if quarkus.quartz.clustered=true
and DB store type.
I don't think that Quartz API has a way to specify that a specific job is clustered or not. It's a global configuration.
So we would need to run the simple in-memory scheduler (quarkus-scheduler
) and Quartz scheduler (quarkus-quartz
) side by side. Which is not possible at the moment (for example both extensions provide an implementation of io.quarkus.scheduler.Scheduler
).
So we would need to run the simple in-memory scheduler (quarkus-scheduler) and Quartz scheduler (quarkus-quartz) side by side
that would be my preferred choice. I do not want to run everything with quartz.
(for example both extensions provide an implementation of io.quarkus.scheduler.Scheduler
right. that is why I was suggesting providing quartz
specific annotations, just like jobrunr
does
So we would need to run the simple in-memory scheduler (quarkus-scheduler) and Quartz scheduler (quarkus-quartz) side by side
that would be my preferred choice. I do not want to run everything with quartz.
I think that we would need a more general solution.
In other words, we would need:
this is very important for us, as we have @Scheduled
non cluster aware timers in our base extensions. so any application running quartz, would turn them into cluster aware timers, which is functionally wrong in our case.
so any application running quartz, would turn them into cluster aware timers, which is functionally wrong in our case.
Yes, any app running Quartz in cluster mode...
fixed by https://github.com/quarkusio/quarkus/pull/42129 thanks a lot @mkouba
Description
Given this fact:
With a clustered setup of Quartz in a multi-pods environment, it is no more possible to schedule in-memory timers or recurrent in-memory tasks in a given pod in order to trigger actions on some beans, using the
@Scheduled
annotation.Does currently exist a recipe to mixt both needs in an elegant way? Or, is it possible to plan some development on the Quarkus-Quartz extension?
Best regards.
Implementation ideas
@QuartzScheduled
annotation@Scheduled
annotation