Why JTS doesn't starts after server restart until first access?
When we restart a CLM server, the applications do not start until a call to it is made. That is, the asynchronous task scheduler is not started until the a CLM application is accessed.
Is this as designed?
As a result of this behavior I see this problem. Around midnight, the server is brought down for an offline backup. The server is then started, but the data collection jobs do not kick off on their schedule as the task scheduler has not started.
As a workaround, we can add a script to access the JTS server URL so that the scheduler is started. But is there a better way of doing this. Are we missing some configuration setting? or it is expected behavior?
2 answers
I'm presuming this is an OSGi lazy-loading thing. I didn't look at them all, but I glanced through MANIFEST.MF in several of the RTC jars and they have: Bundle-ActivationPolicy: lazy. I think that's the normal/preferred policy. Looking in JTS admin, I didn't see any advanced properties that seemed they would help adjust that behavior.
I read some on start levels and looking in config.ini, the defaultStartLevel is set to 4. Start levels begin at 0 and go up. As the system requests/increments the start level, bundles at that level get started (in no particular order). On a fresh restart of your machine, it may take a request to force the start level to a point where RTC become usable.