I have been working on integration our current project with Jersey, the webapplication uses Spring for IOC and Quartz scheduling. But post getting the configuration working I notice the following in the log files during startup:
2014-08-15 05:43:10,830 INFO org.quartz.core.SchedulerSignalerImpl.<init>:63 - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
2014-08-15 05:43:10,834 INFO org.quartz.core.QuartzScheduler.<init>:215 - Quartz Scheduler v.1.6.5 created.
2014-08-15 05:43:10,838 INFO org.quartz.simpl.RAMJobStore.initialize:141 - RAMJobStore initialized.
2014-08-15 05:43:10,840 INFO org.quartz.impl.StdSchedulerFactory.instantiate:1229 - Quartz scheduler 'syncSchContext' initialized from an externally provided properties instance.
2014-08-15 05:43:10,841 INFO org.quartz.impl.StdSchedulerFactory.instantiate:1233 - Quartz scheduler version: 1.6.5
2014-08-15 05:43:10,848 INFO org.quartz.core.QuartzScheduler.setJobFactory:2094 - JobFactory set to: org.springframework.scheduling.quartz.AdaptableJobFactory#210e5887
2014-08-15 05:43:10,995 INFO org.quartz.core.SchedulerSignalerImpl.<init>:63 - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
2014-08-15 05:43:10,996 INFO org.quartz.core.QuartzScheduler.<init>:215 - Quartz Scheduler v.1.6.5 created.
2014-08-15 05:43:10,997 INFO org.quartz.simpl.RAMJobStore.initialize:141 - RAMJobStore initialized.
2014-08-15 05:43:10,997 INFO org.quartz.impl.StdSchedulerFactory.instantiate:1229 - Quartz scheduler 'org.springframework.scheduling.quartz.SchedulerFactoryBean#0' initialized from an externally provided properties instance.
2014-08-15 05:43:10,997 INFO org.quartz.impl.StdSchedulerFactory.instantiate:1233 - Quartz scheduler version: 1.6.5
2014-08-15 05:43:10,998 INFO org.quartz.core.QuartzScheduler.setJobFactory:2094 - JobFactory set to: org.springframework.scheduling.quartz.AdaptableJobFactory#cd79d78
2014-08-15 05:43:11,795 INFO org.quartz.core.QuartzScheduler.start:461 - Scheduler syncSchContext_$_NON_CLUSTERED started.
2014-08-15 05:43:11,796 INFO org.quartz.core.QuartzScheduler.start:461 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED started.
What might be causing this initialization to happen twice?
The most common situation that would cause the scheduler to run twice is if the bean that is bean scheduled in included in multiple contexts.
Make sure that the scheduled beans belong only to the root application context.
Related
I am trying to run Terracotta server 10.11 from https://www.terracotta.org/downloads/ to connect it with Ehcache in my Spring boot application. But the problem is that when i run Terracotta server instance using the server\bin\start-tc-server.bat it does not give any error but put the server in DIAGNOSTIC state as shown in logs below.
2022-11-24 14:22:01,660 INFO - Terracotta 5.8.5, as of 2021-12-16 at 22:21:34 UTC (Revision 3695ab2f870d94491c564e87c266555a7d1c096b from UNKNOWN)
2022-11-24 14:22:01,660 INFO - Extensions:
2022-11-24 14:22:01,679 INFO - PID is 23344
2022-11-24 14:22:01,965 INFO - Did not find configuration directory at: C:\Users\user\terracotta\config
2022-11-24 14:22:01,965 INFO - Starting node from config file: C:\Users\user\Downloads\ehcache-clustered-3.10.0-kit\ehcache-clustered-3.10.0-kit\server\conf\cluster.cfg
2022-11-24 14:22:02,266 INFO - Found only one node information in config file: C:\Users\user\Downloads\ehcache-clustered-3.10.0-kit\ehcache-clustered-3.10.0-kit\server\conf\cluster.cfg
2022-11-24 14:22:02,267 INFO - Starting unconfigured node: default-node
2022-11-24 14:22:02,271 INFO - Bootstrapped nomad system with root: C:\Users\user\terracotta\config
2022-11-24 14:22:02,277 INFO - Startup configuration of the node:
client-lease-duration=150s
client-reconnect-window=120s
cluster-name=clustered
failover-priority=availability
offheap-resources=main\:512MB
stripe.1.node.1.bind-address=0.0.0.0
stripe.1.node.1.group-bind-address=0.0.0.0
stripe.1.node.1.group-port=9430
stripe.1.node.1.hostname=localhost
stripe.1.node.1.log-dir=%H/terracotta/logs
stripe.1.node.1.name=default-node
stripe.1.node.1.port=9410
stripe.1.stripe-name=default-stripe
2022-11-24 14:22:02,280 INFO - Logging directory is not set. Logging only to the console
2022-11-24 14:22:02,293 INFO - Available Max Runtime Memory: 1820MB
2022-11-24 14:22:02,314 INFO - Creating server nodeID: NodeID[localhost:9410]
2022-11-24 14:22:02,546 INFO - Initializing LeaseServiceProvider with default lease length of 150000 ms
2022-11-24 14:22:02,548 INFO - Initializing org.terracotta.lease.service.LeaseServiceProvider#4cf92ef3
2022-11-24 14:22:02,549 INFO - Initializing org.terracotta.client.message.tracker.OOOMessageHandlerProvider#40f5b3f9
2022-11-24 14:22:02,556 INFO - Registered MBean with name: DiagnosticRequestHandler
2022-11-24 14:22:02,557 INFO - Registered Diagnostic Service: org.terracotta.nomad.server.NomadServer
2022-11-24 14:22:02,557 INFO - Registered Diagnostic Service: org.terracotta.dynamic_config.api.service.DynamicConfigService
2022-11-24 14:22:02,558 INFO - Registered Diagnostic Service: org.terracotta.dynamic_config.api.service.TopologyService
2022-11-24 14:22:02,558 INFO - Initializing org.terracotta.diagnostic.server.DiagnosticServiceProvider#1bf35727
2022-11-24 14:22:02,561 INFO - Initializing org.terracotta.diagnostic.server.extensions.DiagnosticExtensionsServiceProvider#410ee45a
2022-11-24 14:22:02,804 INFO - Initializing org.terracotta.management.service.monitoring.MonitoringServiceProvider#65c7455b
2022-11-24 14:22:02,804 INFO - Initializing org.terracotta.platform.ServerInfoProvider#240d561b
2022-11-24 14:22:02,806 INFO - Registered dynamic configuration change handler for setting client-reconnect-window: org.terracotta.dynamic_config.server.service.handler.ClientReconnectWindowConfigChangeHandler#74d20602
2022-11-24 14:22:02,809 INFO - Registered dynamic configuration change handler for setting log-dir: org.terracotta.dynamic_config.server.service.handler.NodeLogDirChangeHandler#67c6fc00
2022-11-24 14:22:02,810 INFO - Registered dynamic configuration change handler for setting failover-priority: ConfigChangeHandler#accept()
2022-11-24 14:22:02,810 INFO - Registered dynamic configuration change handler for setting public-hostname: ConfigChangeHandler#accept()
2022-11-24 14:22:02,811 INFO - Registered dynamic configuration change handler for setting public-port: ConfigChangeHandler#accept()
2022-11-24 14:22:02,811 INFO - Registered dynamic configuration change handler for setting cluster-name: ConfigChangeHandler#accept()
2022-11-24 14:22:02,812 INFO - Registered dynamic configuration change handler for setting lock-context: ConfigChangeHandler#accept()
2022-11-24 14:22:02,812 INFO - Registered dynamic configuration change handler for setting logger-overrides: org.terracotta.dynamic_config.server.service.handler.LoggerOverrideConfigChangeHandler#3ba87843
2022-11-24 14:22:02,813 INFO - Registered dynamic configuration change handler for setting tc-properties: org.terracotta.dynamic_config.server.api.SelectingConfigChangeHandler#16df9889
2022-11-24 14:22:02,815 INFO - Initializing org.terracotta.dynamic_config.server.service.DynamicConfigServiceProvider#29ca0612
2022-11-24 14:22:02,815 INFO - Registering implementation-provided service com.tc.services.PlatformServiceProvider#16b645b2
2022-11-24 14:22:02,816 INFO - Registering implementation-provided service com.tc.services.EntityMessengerProvider#3c352805
2022-11-24 14:22:02,816 INFO - Initializing com.tc.objectserver.persistence.NullPlatformStorageServiceProvider#149f57c4
2022-11-24 14:22:02,818 INFO - Registering implementation-provided service com.tc.services.LocalMonitoringProducer#5baa3715
2022-11-24 14:22:02,830 INFO - Creating 4 worker comm threads for default-node - L2_L1
2022-11-24 14:22:02,910 INFO - Registering implementation-provided service com.tc.services.CommunicatorService#7d51aa32
2022-11-24 14:22:02,920 INFO - HealthChecker Started
2022-11-24 14:22:02,952 INFO - Started the server in diagnostic mode
2022-11-24 14:22:02,967 INFO - Server started as default-node
2022-11-24 14:22:02,959 INFO - Terracotta Server instance has started diagnostic listening on all interfaces (address:/0.0.0.0 port:9410)
2022-11-24 14:22:03,177 INFO - Moved to State[ DIAGNOSTIC ]
According to the documentation it should be in ACTIVE state to be running properly. Still i tried to make connection with the server from my Spring boot application but it was also unable to reach it and gave TimeoutException.
I am using the following command to run the server instance:
./start-tc-server.bat -f C:\Users\user\Downloads\ehcache-clustered-3.10.0-kit\ehcache-clustered-3.10.0-kit\server\conf\cluster.cfg
Does anyone have any clue why its not getting to ACTIVE state ? maybe try to run it on your end and see if the server gets to ACTIVE state. Or is there anything i am missing ?
Thanks in Advance.
P.S I tried running older version of Terracotta server from the same downloads page and it easily goes to active state but i cannot use old version since it is not compaitable with Ehcache 3.x
You need to activate the server.
In the kit that you downloaded navigate to /tools/bin and you need to run config-tool.bat activate -f ../../server/conf/cluster.cfg
This will create a folder C:\Users\{user}\terracotta that will contain the configs and logs for the terracotta server, so the next time you start it will use the configs in the folder and automatically go to activate state.
If you need to change configs delete the folder, restart terracotta and activate it again using the config tool.
My spring boot application always starts quartz in non clustered mode.
Below is my configurations:
spring.quartz:
job-store-type: jdbc
jdbc:
initialize-schema: never
properties:
org:
quartz:
scheduler:
instanceId: AUTO
instanceName: myQuartzScheduler
job-store:
dataSource: quartzDataSource
class: org.springframework.scheduling.quartz.LocalDataSourceJobStore
driverDelegateClass: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
useProperties: false
tablePrefix: QRTZ_
misfireThreshold: 60000
clusterCheckinInterval: 5000
isClustered: true
threadPool:
class: org.quartz.simpl.SimpleThreadPool
threadCount: 10
threadPriority: 5
threadsInheritContextClassLoaderOfInitializingThread: true
added dependency
spring-boot-starter-quartz
have quartz job and trigger in place. Application starts and the job gets fired as per the cron. but quartz always starts in non clustered mode:
2022-07-29 11:10:09.810 INFO 86257 --- [ main] o.s.s.quartz.LocalDataSourceJobStore : JobStoreCMT initialized.
2022-07-29 11:10:09.810 INFO 86257 --- [ main] org.quartz.core.QuartzScheduler : Scheduler meta-data: Quartz Scheduler (v2.3.2) 'myQuartzScheduler' 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.springframework.scheduling.quartz.LocalDataSourceJobStore' - which supports persistence. and is not clustered.
What did I miss folks? I need to start quartz in clustered mode. Any help, appreciated. Thank you.
You have probably followed this article on how to build the clustered job scheduler.
In your case however you have used the
job-store:
class: org.springframework.scheduling.quartz.LocalDataSourceJobStore
The property however org.quartz.jobStore.isClustered: true that you later use, does not exist in common spring boot properties. It is a specific property, that is used from a specific JobStore, namely the org.quartz.impl.jdbcjobstore.JobStoreTX
Referenced doc
If you don't have any further conflicts in your properties, just changing into the following should fix the issue.
job-store:
class: org.quartz.impl.jdbcjobstore.JobStoreTX
The hint from #Panagiotis Bougioukos helped.
I had to change the configuration job-store: to jobStore: then the class class: org.quartz.impl.jdbcjobstore.JobStoreTX was honoured and Quartz started in clustered mode.
Finally
spring.quartz:
job-store-type: jdbc
jdbc:
initialize-schema: never
properties:
org:
quartz:
scheduler:
instanceId: AUTO
instanceName: myQuartzScheduler
jobStore:
dataSource: quartzDataSource
.
.
dataSource.quartzDataSource:
driver: com.mysql.cj.jdbc.Driver
URL: jdbc:mysql://${database.host:localhost}:${database.port:3306}/${database.name:mySchema}
user: myUser
password: ******
provider: hikaricp
and defining the quartzDataSource helped.
I use IDEA as my java IDE and now I'm working on a program using springboot and quartz.
I set a breakpoint on the quartz-2.3.0's source code org.quartz.core.QuartzScheduler at line 585, and the breakpoint was enabled and was set to suspend on all thread without any specific trigger conditions.
(A screen shot here)
Then I started the program, and the quartz scheduler began to work. Before the quartz scheduler finished, I terminated the program by pressing the stop button. Although the log printed the message that confirmed the code where the breakpoint on it had been executed. The program didn't suspend at the breakpoint. Is there anything wrong with it?
Here is the log
22:48:13.134 [schedulerFactoryBean_Worker-1] INFO z.e.q.entity.dto.MyJob - Begin to execute job: DEFAULT.job_zyz2_1631439573107
Disconnected from the target VM, address: '127.0.0.1:57808', transport: 'socket'
22:48:23.090 [SpringApplicationShutdownHook] INFO org.quartz.core.QuartzScheduler - Scheduler schedulerFactoryBean_$_DESKTOP-F3S0BUG1631458081508 paused.
22:48:23.419 [SpringApplicationShutdownHook] INFO o.s.s.quartz.SchedulerFactoryBean - Shutting down Quartz Scheduler
22:48:23.420 [SpringApplicationShutdownHook] INFO org.quartz.core.QuartzScheduler - Scheduler schedulerFactoryBean_$_DESKTOP-F3S0BUG1631458081508 shutting down.
22:48:23.420 [SpringApplicationShutdownHook] INFO org.quartz.core.QuartzScheduler - Scheduler schedulerFactoryBean_$_DESKTOP-F3S0BUG1631458081508 paused.
22:48:32.134 [schedulerFactoryBean_Worker-1] INFO z.e.q.entity.dto.MyJob - Succeed to execute job: DEFAULT.job_zyz2_1631439573107
22:48:32.140 [SpringApplicationShutdownHook] INFO org.quartz.core.QuartzScheduler - Scheduler schedulerFactoryBean_$_DESKTOP-F3S0BUG1631458081508 shutdown complete.
22:48:32.141 [SpringApplicationShutdownHook] INFO com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Shutdown initiated...
22:48:32.144 [SpringApplicationShutdownHook] INFO com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Shutdown completed.
Process finished with exit code 130
Dears,
I have a jersey - spring api deployed on apache tomcat 9.0.46. (Jersey to handle restful services JAX-RS and Spring to handle all my beans{controllers, DAO, SessionFactory, JPA etc...}).
Everything works fine on tomcat 9 on windows...
When deploying the exact same war in ubuntu tomcat 9.0.46, the ContextLoader is getting triggered 3 times and I have all my singletons instantiated 3 times. I'm deploying the api on tomcat ports 80 and 443 (https - godady certificate).
once I start tomcat the war is deployed and ports 80 and 443 get started (netstat -tulnp | grep java) and I see in log all singletons instantiated. (pool-2) Applicationcontext class my custom spring #Configuration class and it is getting triggered and DB is accessed without any issues
2021-06-09 14:41:52,128 1104 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 905 ms
2021-06-09 14:41:53,124 2100 [pool-2-thread-1] INFO skd.app.core.ApplicationContext - TASK::cleanExpiredStatuses
then the server takes few minutes (around 10 minutes 14:41 above then 14:51 below) and when port 8005 is started I see again the ContextLoader is triggered again 2 times.
09-Jun-2021 14:51:36.196 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [584,064] milliseconds.
09-Jun-2021 14:51:36.592 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:37.042 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [588,185] ms
2021-06-09 14:51:39,388 696 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 581 ms
09-Jun-2021 14:51:39.632 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:40.013 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war]
and again for the 3rd time:
2021-06-09 14:51:41,989 744 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 605 ms
09-Jun-2021 14:51:42.232 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:42.602 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [2,590] ms
Everything is working fine in windows, only when deploying to ubuntu tomcat, I'm getting this.
Does anyone have a clue why this difference in tomcat behaviour between windows and ubuntu for the same exact WAR file?
I have managed to figure out the problem. The issue was related to tomcat configuration in /conf/server.xml. Multiple Hosts will trigger the context loader to be triggered for each. I was keeping the default appBase to webapps for all host thus triggering the ContextLoader of each my war for each host. Another reason the ContextLoader will triggered multiple times as well is defining the option inside unless you need to load something external to your war.
I recommend reading specs:
https://tomcat.apache.org/tomcat-4.1-doc/config/host.html
I have created a spring boot application to publish the message to the Kafka queue. For that, I am using spring cloud stream and Kafka binder as dependencies. Problem is my application is continuously trying to connect to Kafka broker if it is down for 2 minutes because of the default configuration.
I have reduced that time using the below property and set it to 1000 ms and getting the timeout exception
spring.kafka.properties.request.timeout.ms:1000.
But still, my spring application is running after the exception. I want it to fail if Kafka broker is not available to connect to. I have tried one more property for that spring.kafka.admin.fail-fast=true but still, the application is running.
I have also tried to search for some properties of spring cloud stream and Kafka binder that I can set to fail my application if Kafka broker is not available but couldn't find anything related to that.
Please, help me with this.
Please see below for the log of exception.
Caused by: java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Timed out waiting for a node assignment.
at org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
at org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
at org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:104)
at org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:274)
at org.springframework.cloud.stream.binder.kafka.provisioning.KafkaTopicProvisioner.createTopicAndPartitions(KafkaTopicProvisioner.java:351)
at org.springframework.cloud.stream.binder.kafka.provisioning.KafkaTopicProvisioner.createTopicIfNecessary(KafkaTopicProvisioner.java:325)
at org.springframework.cloud.stream.binder.kafka.provisioning.KafkaTopicProvisioner.createTopic(KafkaTopicProvisioner.java:302)
... 33 common frames omitted
Caused by: org.apache.kafka.common.errors.TimeoutException: Timed out waiting for a node assignment.
2019-05-22 06:06:25 [main] DEBUG o.s.c.s.DefaultLifecycleProcessor - Successfully started bean 'outputBindingLifecycle'
2019-05-22 06:06:25 [main] DEBUG o.s.c.s.DefaultLifecycleProcessor - Starting beans in phase 2147482647
2019-05-22 06:06:25 [main] DEBUG o.s.c.s.binding.BindableProxyFactory - Binding inputs for :interface kafka.stream.RXXXStreams
2019-05-22 06:06:25 [main] DEBUG o.s.c.s.DefaultLifecycleProcessor - Successfully started bean 'inputBindingLifecycle'
2019-05-22 06:06:25 [main] DEBUG o.s.c.s.DefaultLifecycleProcessor - Starting beans in phase 2147483547
2019-05-22 06:06:25 [main] DEBUG o.s.c.s.DefaultLifecycleProcessor - Successfully started bean 'org.springframework.kafka.config.internalKafkaListenerEndpointRegistry'
2019-05-22 06:06:25 [main] DEBUG o.s.b.a.l.ConditionEvaluationReportLoggingListener -
Do you have spring-boot-web libraries as dependency? If that's the case, your application will not exit. A full log will be also very helpful.