Appendix A.3 Considering the timing at which an HTTP session is created

This subsection describes how to implement an application considering the times at which an HTTP session is created and how to check the implementation using the J2EE server log.

Organization of this subsection
(1) Considerations for the implementation of applications
(2) How to check using the J2EE server log

(1) Considerations for the implementation of applications

If you specify settings so that only the HTTP sessions used in applications are created, the memory efficiency of the Explicit memory block improves. Note that a J2EE server has the functionality for using an HTTP session implicitly.

An Explicit memory block and an HTTP session have a one-to-one correspondence. Also, the minimum size of one Explicit memory block is 16 KB (default is 64 KB). If you create one HTTP session, the Explicit heap area uses 16 KB, even if no objects are stored in the HTTP session. Therefore, the memory efficiency becomes better if you create the HTTP sessions that are actually used. For example, assume an application that creates an un-used HTTP session whenever a servlet is accessed, and the HTTP session is not destroyed until the session times out. If you assume that the timeout is 30 minutes and that the servlets are accessed 10,000 times in 30 minutes, a 16 KB[Figure] 10,000 = 160 MB (by default, 640 MB) Explicit heap area will be used.

Also, with the JSPs, an HTTP session is created for each access by default. Therefore, if an HTTP session uses a JSP with an unnecessary processing (for example, the health check of a J2EE server), an unnecessary HTTP session object is generated and the Explicit heap might overflow. With JSPs that do not need sessions, specify settings so that the HttpSession object is not created explicitly. You use the session attribute of the page directive in the settings.

If you cannot change the application, consider using the memory saving functionality of the Explicit heap to be used in the HTTP session. For details on the memory saving functionality of the Explicit heap to be used in the HTTP session, see 8.11 Reducing the memory usage of the Explicit heap used in an HTTP session in the uCosminexus Application Server Expansion Guide. If you use this functionality, even before the HTTP session is destroyed, the objects stored in an Explicit memory block with a low utilization rate are moved and consolidated to another area, and the Explicit memory block with a low utilization rate is automatically released. The relationship of the HTTP sessions and Explicit memory blocks in Application Server becomes many to one. One Explicit memory block can be shared by multiple HTTP sessions, so the utilization rate of the Explicit memory block improves. Due to this, you can reduce the memory usage of the Explicit heap allocated to the HTTP session.

(2) How to check using the J2EE server log

You check whether Explicit memory blocks are being created for unnecessary HTTP sessions, from the contents of the thread dump.

To check:

  1. Start the J2EE server, and execute the business.
    An HTTP session might also be used implicitly in an application. Therefore, do not limit the business to one using the HTTP sessions.
  2. During the execution of the business, execute the eheapprof command to obtain the thread dump.
    Check the values of used/total (Explicit memory block utilization rate) and spaces exist (number of enabled Explicit memory blocks) output to the Explicit heap information.
    An example of output is as follows:

    max 31415926​K, total 162816K, used 150528K, garbage 10004K (0.0% used/max, 91.1% used/total, 6.6% garbage/used), 3 spaces exist

    In this example, the value of used/total is 91.1%. The closer this value is to 100%, the better is the memory efficiency. Check whether this value is a single digit and whether the value of spaces exist greatly exceeds the assumed number of HTTP sessions.