Classloader leak detection in websphere application server

Editor's Notes

• #2: This presentation describes support for Memory leak detection, prevention and Remediation included in IBM WebSphere Application Server V8.5 WebSphere Application Server Version 8.5 provides a top down pattern-based memory leak detection, prevention, and action by watching for suspect patterns in application code at run time. WebSphere Application Server has some means of protection against memory leaks when stopping or redeploying applications. If leak detection, prevention and action are enabled, WebSphere Application Server monitors application and module activity performs diagnostic actions to detect and fix leaks when an application or an individual module stops. This feature helps in increasing application up time with frequent application redeployments without cycling the server.
• #3: What will nameOfFeature do for you?
• #4: WebSphere Application Server now has some means of protection against memory leaks when stopping or redeploying applications. WebSphere Application Server monitors application and module activity and performs diagnostic actions when an application or an individual module is stopped.
• #5: nameOfFeature is used in the following scenarios.
• #6: Class loader memory leak Many memory leaks manifest themselves as class loader leaks. A Java class is uniquely identified by its name and the class loader that loaded it. Classes with the same name can be loaded multiple times in a single JVM, each in a different class loader. Each web application gets its own class loader and this is what WebSphere Application Server uses for isolating applications. An object retains a reference to the class it is an instance of. A class retains a reference to the class loader that loaded it. The class loader retains a reference to every class it loaded. Retaining a reference to a single object from a web application pins every class loaded by the web application. These references often remain after a web application reload. With each reload, more classes are pinned which leads to an out of memory error. Class loader memory leaks are normally caused by the application code or JRE triggered code. JRE triggered leaks Memory leaks occur when Java Runtime Environment (JRE) code uses the context class loader to load an application singleton. These singletons can be threads or other objects that are loaded by the JRE using the context class loader. If the web application code triggers the initialization of a singleton or a static initializer, the following conditions apply:The context class loader becomes the web application class loader. A reference is created to the web application class loader. This reference is never garbage collected. Pins the class loader, and all the classes loaded by it, in memory. Application triggered leaks Categories of application triggered leaks are as follows:Custom ThreadLocal class Web application class instance as ThreadLocal value Web application class instance indirectly held through a ThreadLocal value ThreadLocal pseudo-leak ContextClassLoader and threads created by web applications ContextClassLoader and threads created by classes loaded by the common class loader Static class variables JDBC driver registration: RMI targets For more information on application triggered links, see http://wasdynacache.blogspot.com/2012/01/websphere-classloader-memory-leak.html , http://www.websphereusergroup.org.uk/wug/files/presentations/31/Ian_Partridge_-_WUG_classloader_leaks.pdf , and http://www.ibm.com/support/docview.wss?uid=swg1PM39870 .
• #7: Detection: Issue warnings when a memory leak is detected. Through a combination of standard API calls and some reflection tricks when a web application is stopped, undeployed or reloaded. Prevention is on by default and applies only to JRE triggered leaks. JRE triggered leaks are prevented by initializing singletons at server startup, when the application Server class loader is the context class loader. Action: Take proactive action to fix memory leaks. These actions have reasonable defaults and are configured on a case-by-case basis.protected. Page of 32
• #8: The MemoryLeak service and its mbean are active only in an application server that hosts applications and services requests. This service is not active on a Deployment Manager, node agent, administrative agent, or other servers types like WebSphere proxy server and so on. The leak detection option is disabled by default. You can use Java virtual machine (JVM) custom properties to adjust the leak policy values, such as, enable and disable leak detection, action, and prevention. These custom properties are only applicable to a stand-alone server or managed application server and not to a node agent, admin agent, job manager, or deployment manager. When the application or the server is shutting down, WebSphere Application Server determines the classloaders that have leaked and are held references to all of associated loaded classes and objects. If a classloader leak is detected, a heapdump or systemdump is taken. All persistent configurations of this service are completed using JVM custom properties. There are no administrative console panels. At runtime, use the MemoryLeakConfig and MemoryLeakAdmin mbeans for configuration and administration respectively; however, the configuration changes are not persisted until JVM custom properties are configured. Page of 32
• #9: These JVM custom properties are persisted in the WebSphere Application Server configuration model in the server.xml file. The following code snippet displays the persisted leak policy configuration from the server_home /config/cells/nodes/servers/server.xml file of an unmanaged server: Page of 32
• #10: At runtime the memory leak detection, prevention and policy configuration can be changed using the MemoryLeakConfig mbean. Administration of the Memory leak policy can be carried out using the MemoryLeakAdmin mbean. The leak policy affects how the application server responds to a classloader memory leak when an application or when the server is stopped. You can adjust the Memory leak policy settings by using the wsadmin scripting interface. These changes take effect immediately, but do not persist to the server configuration, and are lost when the server is restarted. Page of 32
• #11: Mbean operations that are exposed to customers to find and fix leaks at runtime via the MemoryLeakAdmin mbean. Page of 32
• #12: A sampling of the different types of leak warnings output when a memory leak is detected. Page of 32
• #14: To recap,..
• #15: This feature exists in two parts. First, it prevents memory leaks through life-cycle that calls various parts of the Java API. Its common that if the web application is the first code to call the Java APIs, the web application class loader will be pinned in memory, causing leaks. The listener ensures that WebSphere Application Server is the first to make a call, and therefore prevents the class loader from being pinned in memory. Second, it handles detection by executing code when a web application is stopped, undeployed or reloaded. It scans the code for standard causes of memory leaks, and where it can, fixes the leaks. Implemented in the WebSphere Application Classloader, there are a series of expandable, standard API calls and some reflection tricks that help this detection feature do its job.
• #16: See the following references for additional information about nameOfFeature
• #17: You can help improve the quality of IBM Education Assistant content by providing feedback.