I have seen this question being posted multiple times, going back as far as 7 years but no proper answer has been posted so I am getting a little desperate.
I saw some posts in which the answer implied that the issue was with the jobs already scheduled. So I deleted my quartz database and recreated it. Even then when I start the springboot REST service, I get the following message in the log;
2022-04-18 18:44:15.091 INFO 19884 --- [ restartedMain]
org.quartz.core.QuartzScheduler : Scheduler meta-data: Quartz
Scheduler (v2.3.2) 'quartzScheduler' with instanceId 'NON_CLUSTERED'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED. Currently in standby mode. Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 5
threads. Using job-store
'org.springframework.scheduling.quartz.LocalDataSourceJobStore' -
which supports persistence. and is not clustered.
Does anybody have any idea.
I have no specific quartz specific configuration in my project.
Related
I wrote a simple Spring app using H2 and embedded Redis server, and I have #Configuration for the embedded Redis server, so that it'll shutdown itself (#PreDestroy) before shutdown. It works fine on POSIX. I've tested it on macOS, arch, ubuntu, and it worked fine on all of them with any IDE or editor (i.e. when I clicked the stop button on IntelliJ or VS Code, both the spring app and the redis server gracefully shutdown after printing something like this).
[InstanceCleaner] --snipped-- : Stopping redis server...
[InstanceCleaner] --snipped-- : Redis exited
[ionShutdownHook] --snipped-- : Closing JPA EntityManagerFactory --snipped--
[ionShutdownHook] --snipped-- : HHH000477: Starting delayed evict --snipped--
[ionShutdownHook] --snipped-- : HikariPool-1 - Shutdown initiated...
[ionShutdownHook] --snipped-- : HikariPool-1 - Shutdown completed.
However, for some reason, when I tried to stop the app on Windows by doing the exact same thing (i.e. clicking the stop button or disconnect button or stop button on Spring extension), the spring app doesn't shutdown gracefully.
It just stops without doing anything, and it leaves the embedded redis server running. This already-running redis server prevents me from running the app again. To start the app again without any problem, I either need to terminate the redis process manually, or use other ways to shutdown the app gracefully (I found two methods, one of them is sending ctrl + c to the terminal which runs the spring app, and the other one is making a controller which triggers the shutdown and map them on /shutdown and use the url everytime I want to shutdown the app).
It's not exactly a huge hassle, but I'd like to know why I got this behavior on Windows but not on POSIX (and a fix if there is one).
I'm trying to create a scheduler in spring using Quartz. During the application booting, job, trigger and scheduler have been configured. In executeJob(), I'm printing hello and invoking an endpoint. Hello is getting printed as per the schedule, but the endpoint is not being invoked.
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.
We have a spring boot application using spring-kafka (2.2.5.RELEASE) that always gets this error when starting up:
Could not configure topics
org.springframework.kafka.KafkaException: Timed out waiting to get existing
topics; nested exception is java.util.concurrent.TimeoutException
However, the application continues to startup:
org.springframework.kafka.KafkaListenerEndpointContainer#0-0-C-1]
INFO o.s.k.l.KafkaMessageListenerContainer - partitions revoked: []
INFO o.s.k.l.KafkaMessageListenerContainer - partitions assigned: [my-reply-topic-1]
INFO o.s.k.l.KafkaMessageListenerContainer - partitions assigned: [my-request-topic-0]
INFO o.s.b.w.e.tomcat.TomcatWebServer -
Tomcat started on port(s): 8080 (http) with context path ''
At this point, the application interacts with Kafka as expected.
We like to keep our logs clean, so we would like to understand why this Exception is thrown. Also, it is a bit confusing, because when we move to a different environment where the networking has not been established between the application and the kafka broker(s), we get the same error, but the application does not function. Having the same Exception occur when there is truly a problem and when it can be ignored is irksome when trying to troubleshoot connectivity issues.
Is there a way, on application startup, to determine whether connectivity has been established with Kafka rather than just waiting for a timeout message (which may be a red herring anyway)?
If the topic(s) exist already, remove any NewTopic beans from the application context and the KafkaAdmin won't try to connect to the broker at all.
Currently, we have four JMS listener containers that are started during the application start. They all connect through Apache ZooKeeper and are manually started. This becomes problematic when a connection to ZooKeeper cannot be established. The (Wicket) application cannot start, even though it is not necessary for the JMS listeners be active to use the application. They simply need to listen to messages in the background, save them and a cron job will process them in batches.
Goals:
Allow the application to start and not be prevented by the message containers not being able to connect.
After the application starts, start the message listeners.
If the connection to one or any of the message listeners goes down, it should attempt to automatically reconnect.
On application shutdown (such as the Tomcat being shutdown), the application should stop the message listeners and the cron job that processes the saved messages.
Make all of this testable (as in, be able to write integration tests for this setup).
Current Setup:
Spring Boot 1.5.6
Apache ZooKeeper 3.4.6
Apache ActiveMQ 5.7
Wicket 7.7.0
Work done so far:
Define a class that implements ApplicationListener<ApplicationReadyEvent>.
Setting the autoStart property of the DefaultMessageListenerContainer to false and start each container in the onApplicationEvent in a separate thread.
Questions:
Is it necessary to start each message container in its own thread? This seems to be overkill, but the way the "start" process works is that the DefaultMessageListenerContainer is built for that listener and then it is started. There is a UI component that a user can use to start/stop the message listeners if need be, and if these are started sequentially in one thread, then the latter three message containers could be null if the first one has yet to connect on startup.
How do I accomplish goals 4 and 5?
Of course, any commments on whether I am on the right track would be helpful.
If you do not start them in a custom thread then the whole application cannot be fully started. It is not just Wicket, but the Servlet container won't change the application state from STARTING to STARTED due to the blocking request to ZooKeeper.
Another option is to use a non-blocking request to ZooKeeper but this is done by the JMS client (ActiveMQ), so you need to check whether this is supported in their docs (both ActiveMQ and ZooKeeper). I haven't used those in several years, so I cannot help you more.
I'm using spring 3.0, jpa hibernate for the persistence,so i want to use quartz 1.8.5 with spring 3.0 to call my method that starts with checking some paramerter in DB before sending the files.
The problem is that the DB code is never called and in the log file i have the following message:
[QuartzScheduler] INFO - Scheduler meta-data: Quartz Scheduler
(v1.8.5) 'org.springframework.scheduling.quartz.SchedulerFactoryBean#0'
with instanceId 'NON_CLUSTERED'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.
The code without the quartz part (Spring, Jpa .. ) works fine.
I test the same quartz config to call a simple method printHello and it works well also.
Any indication will be really appreciated.
Thank's