quartz not honoring clusterCheckInInterval property in a spring application - java

I have quartz scheduler integrated with spring application. Triggers on quartz works as expected. I want to increase clusterCheckInInterval property.
so here is what I have
org.quartz.jobStore.isClustered=true
org.quartz.jobStore.clusterCheckinInterval=30000
but I dont see this setting being honored. I see only the default value of 7500 being used in qrtz_scheduler_state table. Here is screenshot.
I am pretty sure the properties are loaded correctly since I have defined my dataSource connection in this property. I also flipped isClustered to false and I could see NO entries in qrtz_scheduler_state as expected.
I am using quartz 2.3.0 (Java).

Related

quartz spring boot with oracle DB

I have decided to go with quartz with data base option. I configured a simple job and deployed my changes. These changes are reflected in oracle quartz tables. The table QRTZ_TRIGGERS recorded the trigger name and trigger type as SIMPLE. I wanted to update the simple job to a cron job and I made those changes in spring configuration. Local is working as expected. When I deployed the changes to dev, build went successfully. QRTZ_TRIGGERS did not reflect these changes. The trigger type still shows as SIMPLE. I'm expecting this to be updated by spring on load and create a record in QRTZ_CRON_TRIGGERS and delete the entries in QRTZ_SIMPLE_TRIGGERS
This is not happening. Is there a prop that I can add in spring configuration so that these changes will be picked up when the server starts (for first time)?
overwriteExistingJobs set this prop to true in
setOverwriteExistingJobs
public void setOverwriteExistingJobs(boolean overwriteExistingJobs)
Set whether any jobs defined on this SchedulerFactoryBean should overwrite existing job definitions. Default is "false", to not overwrite already registered jobs that have been read in from a persistent job store.

QuartzDesk cannot manage the Quartz Jobs and Trigger in a Spring Boot 2 application

We let the Quartz Jobs in our Spring Boot 2 application be managed by QuartzDesk:
https://www.quartzdesk.com/documentation/how-it-works
QuartzDesk consists of three parts: the Web UI (its main purpose) which runs on its own Tomcat and from which you can manage the Quartz Jobs and Quartz Trigger from remote by RMI or JMXMP. Then there is the QuartzDesk Agent which the Spring Boot 2 application must adopt by setting a java agent (java -javaagent:agent.jar ...) when it starts. Last but not least the Spring Boot 2 application must use the QuartzDesk Public API just by declaring a further dependency in the pom.xml.
For Quartz in general we hava a central JDBC Jobstore in which the all the Quartz stuff is saved. The Spring Boot 2 application runs on two instances which are load balanced.
Our problem is that the Quartz Jobs and Trigger cannot be managed by the QuartzDesk Web UI. When you set up in QuartzDesk Web UI the connection to each instance then all Quartz Jobs and Trigger are there in advanced created. The worst thing however is that any changes from this central management console have no effect even though QuartzDesk Web UI confirms it mistakenly.
The problem was a wrongly configured property for the Quartz JDBC Jobstore, i.e. its datasource:
quartz.datasource.auto-commit=false
Changing it to true solved the problem and Quartz jobs and trigger were finally configurable.

is there an pool of connections by default in Spring Boot 2.x with HikariCP?

I'm developing a web service with Spring Framework (spring boot 2.1.5), that has to generated a pool of connections (without JNDI).
I have heard that Spring Data (when the version of spring boot is higher than 2.X) implements HikaryCP for managing the connections, but I do know if this happen automatically or I have to activated with some configuration.
If it is true, Every services that use Spring Data, and whose version of Spring Boot is higher than 2.x, have by default a pool of connections always activated and working. is it true?
If it is true, Do Someone have any bibliography where i can read the default properties of HikariCP.
---------------------------------Added--------------------------
I have found the follow information in a book:
https://books.google.com/books?id=au1mDwAAQBAJ&pg=PA40&dq=spring+boot+and+HikariCP&hl=en&sa=X&ved=2ahUKEwjmh4aY68vkAhUWrp4KHTbKCq4Q6AEwAXoECAEQAg#v=onepage&q=spring%20boot%20and%20HikariCP&f=false
With Spring Boot 2.0, the default basic DataSoruce initialization is only enabled for embedded database and will be disabled as soon as a production database is used. Te configuration property spring.datasource.initialization-mode (with values always or never), which replaces the old spring.datasource.initialize configuration property, can be user for more control.
Hikari is on by default in Spring boot 2+
If we are using Spring Boot 2.0 and onwards, Spring Boot selects HikariDataSource by default
All hikari properties in github with full explanation
maximumPoolSize
This property controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. Basically this value will determine the maximum number of actual connections to the database backend. A reasonable value for this is best determined by your execution environment. When the pool reaches this size, and no idle connections are available, calls to getConnection() will block for up to connectionTimeout milliseconds before timing out. Please read about pool sizing. Default: 10

Flyway, spring boot and application start without database

I'm trying to make Spring Boot application with Flyway (and Hikari pool) to start the server even when the DB is not available at that time.
I need to support cases when:
1. DB is not available when applicaition starts (it should run Flyway after DB starts, it can be up to 30 mins).
2. DB goes offline during the application lifetime and then goes back up.
I got a problem with the first case, Flyway always tries to do migrations even when DB is not available and application stops.
I tried adding spring.datasource.continue-on-error: true but Flyway ignores that, and I couldn't find any flyway configuration that would allow such operation.
Is it possible or should I wrap Flyway and do it myself?
Spring boot 2.1.4
A couple of points to consider
What is the desired behavior of the application when the DB is really not available when the instance of java application? Ok, so flyway won't start, but how the application will be able to handle requests that will have to reach the database?
Flyway itself relies on DataSource bean, maybe on hibernate if you use it, and these are much more complicated infrastructures than flyway itself?
Maybe if the database is not available the application won't need to start at all?
Instead it worth to rely on orchestrators (like kubernetes, ECS or whatever that will recognize that the application didn't start and will try to retrigger the start again, again, and again till the database will be ready)?
This is my recommendation in general.
Now, assuming find answers to all these questions and still, want to proceed with this path:
Spring Boot by itself works like this when it comes to flyway integration:
If the relevant classes (Flyway class) exist on classpath and spring.flyway.enabled=true then the bean of flyway starts and spring boot does its magic.
Technically the relevant auto configuration can be found in class org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration (org.springframework.boot:spring-boot-autoconfigure module)
I think the way to go is to disable flyway, and given that fact that beans like DataSource are available (somehow) - create a Flyway Bean by yourself and trigger the migration in some kind of loop in the background that will exit only if the migration actually succeeds (or already applied)

What's Wrong with this Quartz Configuration?

I have Quartz Scheduler running within WebLogic 12.1.3 and backed by a JobStoreCMT, but its behavior doesn't match the configuration (see below). What am I doing wrong?
Background
Quartz has jobs that are loaded from an XML file on startup and run periodically. Some of those jobs spawn one-time jobs. Also, there are one-time jobs that are manually triggered by users. The user-initiated jobs are done from EJBs that have container-managed transactions.
Questions
The transactions in the job classes are not active in the job's execute() method. I have to call begin/commit/rollback. Shouldn't that be taken care of since wrapJobExecutionInUserTransaction is set to true? That's what the documentation says.
The documentation also says that when using XMLSchedulingDataProcessorPlugin with JobStoreCMT, org.quartz.plugin.jobInitializer.wrapInUserTransaction must be set to true. However, when I do that I get a duplicate transaction exception. What's going on?
WebLogic takes forever to shut down whenever Quartz is enabled even though all of the jobs run quickly. From the logs it looks like WebLogic is waiting for the transactions to time out. Is something in the config contributing to this?
Configuration
org.quartz.scheduler.skipUpdateCheck=true
org.quartz.scheduler.instanceName=MyTaskScheduler
org.quartz.scheduler.threadsInheritContextClassLoaderOfInitializer=true
org.quartz.scheduler.instanceId=AUTO
org.quartz.scheduler.wrapJobExecutionInUserTransaction=true
org.quartz.scheduler.userTransactionURL=javax.transaction.UserTransaction
org.quartz.scheduler.idleWaitTime=30000
org.quartz.scheduler.dbFailureRetryInterval=15000
org.quartz.scheduler.batchTriggerAcquisitionMaxCount=1
org.quartz.scheduler.batchTriggerAcquisitionFireAheadTimeWindow=0
org.quartz.scheduler.makeSchedulerThreadDaemon=false
org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount=20
org.quartz.threadPool.threadPriority=5
org.quartz.threadPool.makeThreadsDaemons=false
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.oracle.weblogic.WebLogicOracleDelegate
org.quartz.jobStore.dataSource=MyDataSource
org.quartz.jobStore.nonManagedTXDataSource=MyDataSourceNonXA
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.useProperties=false
org.quartz.jobStore.misfireThreshold=60000
org.quartz.jobStore.isClustered=true
org.quartz.jobStore.clusterCheckinInterval=15000
org.quartz.jobStore.maxMisfiresToHandleAtATime=20
org.quartz.jobStore.txIsolationLevelSerializable=false
org.quartz.jobStore.txIsolationLevelReadCommitted=false
org.quartz.dataSource.MyDataSource.jndiURL=MyDataSource
org.quartz.dataSource.MyDataSource.java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
org.quartz.dataSource.MyDataSource.java.naming.provider.url=t3://localhost:7003
org.quartz.dataSource.MyDataSourceNonXA.jndiURL=MyDataSourceNonXA
org.quartz.dataSource.MyDataSourceNonXA.java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
org.quartz.dataSource.MyDataSourceNonXA.java.naming.provider.url=t3://localhost:7003
org.quartz.plugin.jobInitializer.class=org.quartz.plugins.xml.XMLSchedulingDataProcessorPlugin
org.quartz.plugin.jobInitializer.fileNames=E:/tasks.xml
org.quartz.plugin.jobInitializer.failOnFileNotFound=true
org.quartz.plugin.jobInitializer.scanInterval=0
org.quartz.plugin.jobInitializer.wrapInUserTransaction=false
Any help is appreciated.

Categories

Resources