Scaling and Recovery
The following sections outline key features of the application, including its health check mechanism, background job recovery, and cache bootstrap processes:
Health Check
The application includes a health check URL, accessible at CONTEXT_PATH/hc/ping.spr. This URL, when queried with the optional parameters disableCacheCheck (default: false) and disableDatabaseCheck (default: false), returns a 200 HTTP status code when the application is functioning optimally. Conversely, a 500-status code is returned to indicate potential issues.
The disableCacheCheck parameter allows for bypassing cache-related health checks, while the disableDatabaseCheck parameter enables skipping database health checks. This mechanism facilitates granular control over the health check process and enables more targeted troubleshooting.
Background Job Recovery
Quartz, a robust scheduling framework, ensures high availability and reliability by enabling job failover across multiple nodes. If a node executing a job crashes, Quartz's clustering mechanism seamlessly transfers the job to another available node. This ensures uninterrupted job execution, even in the face of node failures. This failover capability is achieved by utilizing a shared job store, typically a database, where job information has persisted. When a node goes down, other nodes can access this shared store and take over the execution of pending jobs.
Cache Bootstrap
Ehcache Cache Bootstrap is employed to ensure that critical cache data is available on the server at startup. By pre-populating the cache with essential data from a remote cluster node, the application can immediately begin serving user requests efficiently.
Was this helpful?