When the Web applications are reloaded, you can use the delayed reloading functionality and minimize the period for which the J2EE application service is stopped. Also, with the reloading of the Web applications, the session information generated before the application is reloaded is inherited and can be used even after reloading. This subsection describes the delayed reloading of the Web applications and the inheritance of the session information.
By default, if a configuration file update is detected, the reload processing is executed as follows:
In this case, the longer the processing time of requests being processed, the greater is the delay in starting the processing of new requests, and the period during which the application service is stopped for new requests becomes longer. To avoid this, we recommend that you set up delayed reloading. If you use the delayed reloading functionality, the pending time of requests being processed reduces and the period for which the application service is stopped is minimized.
With the delayed reloading functionality, you set whether this functionality is to be used, and the time until the reload processing is started (maximum delay time). It you use the delayed reloading functionality, new requests can be received until the processing of the request being processed is complete. When the number of requests being processed becomes 0, the reload processing starts and the new requests are added to the pending list. However, whether the number of requests being processed becomes 0 depends on the access state. When the requests are continuous, the reload processing cannot be started. In such cases, specify the maximum delay time from the detection of a configuration file update until a new request is added to the pending list. If the maximum delay time lapses, the subsequent new requests are added to the pending list and the reloading starts after the processing of the request being processed is complete.
The following figure shows the difference in the periods for which the application service is stopped when delayed reloading is set and when delayed reloading is not set.
Figure 13-13 Differences in the periods for which the application service is stopped
When the maximum delay time is set for delayed reloading, if the configuration file update is detected and the time specified for the interval for configuration file update lapses, the monitoring of the requests that are being processed and the counting of the maximum delay time for delayed reloading starts. For example, when the maximum delay time is set as five minutes, the time when the reload processing starts differs depending upon the access state as follows:
When the Web applications are reloaded, the session information generated before the execution of reloading is inherited and used even after reloading.
When the Web applications are reloaded, the session information (objects registered in the javax.servlet.http.HttpSession object) is serialized and is output to the session information file. The session information is read from the session information file and is de-serialized on the class loader used after the reloading process. Note that the time required to serialize and de-serialize depends on factors such as the number of sessions generated on the Web application and the size of objects registered in the javax.servlet.http.HttpSession object.
The session information file is created when the reload processing starts and is deleted when the reload processing ends. The session information file is created even if the session does not exist when the reloading process is executed.
The session information file contains information that is auto-generated by Web container (2 kilobytes) and the session information. The session information depends on the number of sessions and the session information (objects) registered in the session.
Check the size of the session information file from the serialize completion message that is output during reloading and calculate the size based on the number of sessions. An example of a serialize completion message is as follows:
KDJE39168-I The serialization of session objects has finished. (J2EE application = app1, context root = /examples, number of sessions = 10, session information file size(byte) = 12345) |
In this example of output, there are 10 sessions for context root name 'examples' on the Web application 'app1' and the size of session information file is 12,345 bytes.