This article explains how to configure the WebLogic application server to shutdown itself if fatal errors are detected while handling application lifecycle events.
Note: the steps mentioned in this article were tested with WebLogic 12.1.1
WebLogic application server allows us to register listeners for handling application’s lifecycle events. This allows us to control the behavior during deployment, undeployment and redeployment of the application. (See reference #1)
Recently, my colleagues mentioned a problem they were facing in production. There was a load balancer between the client and the server. The load balancer would start sending requests to the server as soon as it found the server’s listen port open. The application had a lifecycle listener which initialized the application. If an exception was thrown from a lifecycle method, the application initialization would be interrupted but the server still opened the listen port. The load balancer would find the listen port open and start sending requests to the server. The requests would fail because the application was not initialized properly. The operators would find the server to be running and incorrectly conclude that the application was initialized properly; the operators were not expected to monitor the log files of hundreds of servers ! An hour or so after starting the server, the monitoring team would realize that the request failure rate is abnormally high and it would take another hour or so to fix the problem and the restart the application. Until then, the client requests served by this server would keep on failing.
Had the server not opened its listen port, the load balancer would not have sent requests to this server; instead, the load balancer would have redirected the requests to other live servers. The request failures would have been avoided.
So, what they desired is that (somehow) the WebLogic server should shutdown automatically if fatal errors are detected while handling application lifecycle events.
The documentation of WebLogic application lifecycle event listeners (see reference #1) does not explain how to achieve this.
But I found another way.
WebLogic also supports server-level startup and shutdown classes. (see reference #2).
The server-level startup class has a configuration option called ‘Failure is Fatal’. (see reference #3). If this option is selected, a failure in this startup class causes the server to shutdown itself.
So, all that I had to do was:
- Create a server-level startup class which throws an exception when it is informed that a fatal error has occured.
- Deploy the startup class to the server.
- Select the ‘Failure is Fatal’ option for this startup class.
- Configure the startup class to execute after the application lifecycle events are handled.
- Let the application lifecycle event handler inform the startup class when fatal error occurs while handling the lifecycle events.
Step 1: Create a server-level startup class which throws an exception when it is informed that fatal error has occurred
Step 2: Deploy the startup class to the server
Do the following:
- Configure the the startup class in the server. (see reference # 4)
- Deploy the startup class to the server. (see reference # 5)
- Add the startup class to the server’s classpath. (see reference # 6)
See reference # 7 for complete details.
Step 3: Select the ‘Failure is Fatal’ option for the startup class
See reference #4, #8 and #9 for more information.
Step 4: Configure the startup class to execute after the application lifecycle events are handled
Uncheck the “Run Before Application Deployments” and “Run Before Application Activations” options for the startup class.
See reference #8 for the meaning of these options.
See reference #5 for more information on how to configure these options.
Step 5: Make the application lifecycle event handler inform the startup class when fatal error occurs while handling the lifecycle events
How it works
When the lifecycle event handler detects a fatal error, it sets the value of the boolean field,
hasFatalFailures, of the startup class to true. After the application has been activated, but before the listen port is opened, the server executes the startup class. If the field
hasFatalFailures is true, the startup class’s main method throws an exception. On catching the exception, the server checks the value of ‘Failure is Fatal’ option. Because this option is selected, the server shuts down itself.
Following are some logs which are printed on the standard output during this process: