Quarkus and Quartz and Configurations especially for JobStoreCMT?

[BillEllis]

Hi,

I'm puzzled with how Quarkus wraps Quartz, in particular for JobStoreCMT.

Quartz provides these configurations: http://www.quartz-scheduler.org/documentation/quartz-2.3.0/configuration/
And Quarkus provides these: https://quarkus.io/guides/quartz#quartz-configuration-reference

Maybe first a quick question to check an assumption:
If we are using Quarkus/Quartz, should we only use the Quarkus configuration options?

And, more specifically:
Quartz, where the store-type is "JobStoreCMT" requires two data-sources: http://www.quartz-scheduler.org/documentation/quartz-2.3.0/configuration/ConfigJobStoreCMT.html -- Quarkus provides "quarkus.quartz.datasource" (singular) -- and suggests that the default datastore shall suffice. (confusingly, it also cites the 'db' store, which I guess really means any store-type except 'ram'?).

Basically, if I'm using Quarkus/Quartz, with store-type as "jdbc-cmt", what is the default behaviour? How is the dual managed/unmanaged datastores handled? And, what things do I totally need to configure, to wire it up correctly?

Bill

[quarkus-bot[bot]]

/cc @machi1990, @mkouba

[machi1990]

Hi @BillEllis thanks for raising this.

confusingly, it also cites the 'db' store, which I guess really means any store-type except 'ram'?

You can read it that but I think that this is more of a left over after the db store was deprecated. I think the quarkus.quartz.datasource documentation has to be updated to reflect that.

If we are using Quarkus/Quartz, should we only use the Quarkus configuration options?

Yes the quarkus configuration is the way to use it. We've not exposed all the underlying quartz configuration but they can be exposed given the use case.

As for the jdbc-cmt store configuration of the datasource, the provided Quarkus data source is currently used to configure both the managed/umanaged quartz datastores.

[BillEllis]

Hi, many thanks for the clarifications.

We've not exposed all the underlying quartz configuration... can be exposed given the use case...

I realise now, that, in Quarkus, "org.quartz.scheduler.idleWaitTime" is at the default of 30,000 (30 seconds) - and is not configurable.

I think this basically means that: trigger behaviour will be weirdly stuttering if you schedule jobs for anytime between now and 30 seconds into the future. A note, or nod to that, in the documentation could have been handy for me.

I'm not sure if you'd want to expose that setting, however! I'm kind of realising that Quarkus/Quartz is architecturally positioned for regular running tasks -- the documentation is even headed "SCHEDULING PERIODIC TASKS" -- and the default value does rather make sense in that context.

[machi1990]

I realise now, that, in Quarkus, "org.quartz.scheduler.idleWaitTime" is at the default of 30,000 (30 seconds) - and is not configurable.

Correct. This configuration and some others haven't been exposed yet. That does not mean they cannot be expose. We have basically been expose some of the configurations on the case by case and the use/need to configure them. E.g recently (#24105), we made it possible to configure the misfireThreshold, something which we picked a good default for and used it before exposing it.
I'd say, you can open an issue to have a configuration A or B exposed.

[polando]

Hi @BillEllis thanks for raising this.

confusingly, it also cites the 'db' store, which I guess really means any store-type except 'ram'?

You can read it that but I think that this is more of a left over after the db store was deprecated. I think the quarkus.quartz.datasource documentation has to be updated to reflect that.

If we are using Quarkus/Quartz, should we only use the Quarkus configuration options?

Yes the quarkus configuration is the way to use it. We've not exposed all the underlying quartz configuration but they can be exposed given the use case.

As for the jdbc-cmt store configuration of the datasource, the provided Quarkus data source is currently used to configure both the managed/umanaged quartz datastores.

Hi, I am not following what it means that it only uses QUARKUS_QUARTZ_DATASOURCE for both of the data sources, the data sources need to have different configs, so how it can be used that way?

[pooja-soni]

Hi Team,

We are using Quartz with property org.quartz.jobStore.driverDelegateClass where we are giving our custom delegate class. We are planning to migrate to Quarkus but in Quarkus quartz above property is missing and i couldn't find any way to use custom delegate class. Please suggest. @machi1990

[machi1990]

Support for this was recently introduced in #44064 targeting 3.17 release.