+

Search Tips   |   Advanced Search

Configure the memory leak policy


Overview

The leak detection policy for the WebSphere Application Server is turned off by default. We can configure a leak detection, prevention, and action policy to accommodate the applications and environment so that potential memory leaks are reported and acted upon. Leak detection, prevention, and proactive fixing provides for protection and resiliency for servers that face persistent out of memory errors. When a classloader memory leak is detected, WebSphere Application Server writes informational messages in the log and takes JVM heapdumps for troubleshooting. Optionally, we can choose to have WAS mitigate, and if possible, fix the memory leak using reflection and other techniques.

A common error in Java EE applications is a classloader memory leak. A memory leak can result from subtle application bugs or a more complex use, such as third party libraries. System resources, such as CPU time due to garbage collection and the Java heap are consumed when a leak is present. A system can become unresponsive even though all other resources are available. Unless a protection and early warning system is built in, the system might remain in this degraded state and ultimately die due to an out of memory error.

We can configure WAS to detect, prevent, and take action, if possible, on classloader memory leaks using the memory leak detection policy. For more information about memory leaks, read the Memory Leaks in Java Platform, Enterprise Edition applications topic.

The leak detection option is disabled by default. We can use 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, WAS 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.

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.

Tip: Configure the JVM com.ibm.ws.runtime.component.disableMemoryLeakService custom property to permanently disable the service.


Configure the memory leak policy

  1. Create or modify JVM custom properties to enable various aspects of the memory leak service, based on the table that follows. Read Java virtual machine custom properties to change the values of the JVM custom properties.

    • com.ibm.ws.runtime.component.MemoryLeakConfig.detectAppCLLeaks

      When the server is shutting down or an application stops, WAS determines the classloaders that have leaked and issues warnings and other additional information that aids in debugging the memory leak. See also the Improved classloader leak detection PMR.

      Default: false

    • com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks

      Enable proactive classloader leak mediation and fixing. When true, WAS mediates on behalf of the application to remedy any classloader leaks that are detected.

      Default: false

    • com.ibm.ws.runtime.component.MemoryLeakConfig.preventJreMemoryLeaks

      Enable WAS to eliminate certain classes of memory leaks that are caused by the JRE loading singletons on the thread context classloader.

      Default: true

    • com.ibm.ws.runtime.component.MemoryLeakConfig.generateHeapDumps

      Set to true to cause a heapdump to be created when a memory leak is detected .

      Default: true

    • com.ibm.ws.runtime.component.MemoryLeakConfig.leakSweeperDelay

      Delay after an application or module stops to check for classloader leaks.

      Default: 10000 (milliseconds)

    • com.ibm.ws.runtime.component.MemoryLeakConfig.monitorSystemApps

      Set to true to watch for memory leaks on system applications that are shipped by IBM, such as the administrative console.

      Default: false

      We can fine tune the leak action policy behavior using the following thread and timer leaks JVM custom properties. The ThreadLocal, thread, timer and static leak custom properties are applicable only if com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks is set to true.

    • com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesInterruptThreads

      Set to true for WAS to attempt to interrupt threads that are started by the web application. Interrupting threads is performed using the Thread.interrupt() method. There is a possibility that the target thread might not respond to the interrupt.

      Default: true

    • com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesHttpClientKeepAliveThread

      If an HttpClient keep-alive timer thread is not started by this web application and is still running, WAS changes the context class loader from the current classloader to its parent to prevent a memory leak. The keep-alive timer thread stops on its own when the keep-alive threads all die. However, on a busy system that might not happen for some time.

      Default: true

    • com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesStopTimerThreads

      Set to true for WAS to stop any java.util.TimerThreads that are started by the web application.

      Default: false

    • com.ibm.ws.runtime.component.MemoryLeakConfig.jvmThreadGroupNames

      List of ThreadGroup names to ignore when scanning for threads that are started by the web application that must be shut down. This list is delineated by underscores.

      Default: system__RMI Runtime

      The following static class variable leaks properties apply only if com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks is set to true.

    • com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesStatic

      Set to true for WAS to attempt to make final fields null from loaded classes when a web application stops, as a work around for garbage collection bugs and application coding errors. Applications without memory leaks using recent JVMs should operate correctly when this option is set to false.

      Default: false

    • com.ibm.ws.runtime.component.MemoryLeakConfig.filterPrefixes

      Member attributes starting with these filters are not set to null when clearReferencesStatic is true.

      Default: java javax com.ibm org sun com.sun. The list is delineated by spaces.

      The following Threadlocal leaks properties apply only if com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks is set to true.

    • com.ibm.ws.runtime.component.MemoryLeakConfig.checkThreadLocalLeaks

      Determines if ThreadLocal leaks should be checked when an application stops.

      Default: false

    • com.ibm.ws.runtime.component.MemoryLeakConfig.clearReferencesThreadLocal

      Eliminate threadlocal leaks by renewing threads in the threadpool when an application stops. Applies to distributed platforms.

      Default: true

      The following properties apply only if clearReferencesThreadLocal is set to true.

    • com.ibm.ws.runtime.component.MemoryLeakConfig.renewThreadPoolNames

      Threadpool names that WAS must renew when a threadlocal leak is detected.

      Default: WebContainer" list is delineated by spaces.

    • com.ibm.ws.runtime.component.MemoryLeakConfig.threadPoolRenewalDelayFactor

      Control the total amount of time to wait for thread pool to be renewed. The amount of time to wait for threadpool renewal = threadPoolRenewalDelayFactor * threadPool.getKeepAliveTime()

      Default: 10. For the web container threadpool, the renewal delay is (10 * 60000 ms) 6 minutes.

    • com.ibm.ws.util.ThreadPool.DEFAULT_THREAD_RENEWAL_DELAY

      Threads in the pool renew after an application stops. Avoid renewing all threads at the same time. This delay is observed between two threads being renewed.

      Default: 1000 (value is in ms). If the value is negative, threads are never renewed.

      These JVM custom properties are persisted in the WAS configuration model in the server.xml file. The following code snippet displays the persisted leak policy configuration from...

        server_home/config/cells/nodes/servers/server.xml

      ...of an unmanaged server: 

        <jvmEntries xmi:id="JavaVirtualMachine_1183122130078" 
            verboseModeClass="true" 
            verboseModeGarbageCollection="true" 
            verboseModeJNI="false" runHProf="false" 
            hprofArguments="" 
            debugMode="false" 
            debugArgs="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777" 
            genericJvmArguments="-agentlib:getClasses -Xquickstart  -Xalwaysclassgc" 
            executableJarFileName="" 
            disableJIT="false">

    <systemProperties xmi:id="Property_1317048628648" 
                      name="com.ibm.ws.runtime.component.MemoryLeakConfig.detectAppCLLeaks"	
                      value="true"	/>
	<systemProperties xmi:id="Property_1318975518491" 
                      name="com.ibm.ws.runtime.component.MemoryLeakConfig.clearAppCLLeaks"	
                      value="true"	/>
	<systemProperties xmi:id="Property_1318955284241" 
                      name="com.ibm.ws.runtime.component.MemoryLeakConfig.generateSystemDumps"	
                      value="false"	/>
	<systemProperties xmi:id="Property_1319119976147" 
                      name="com.ibm.ws.runtime.component.MemoryLeakConfig.generateHeapDumps"	
                      value="true"	/>
	<systemProperties xmi:id="Property_1317048628649" 
                      name="com.ibm.ws.runtime.component.MemoryLeakConfig.monitorSystemApps"	
                      value="false"	/>
</jvmEntries>

    • Click Apply.

    • Click OK.

    • Save the changes. Make sure that a file synchronization is performed before restarting the servers.

    • Restart the Application Server for the changes to take effect.


Example

The Memory Leak policy for WAS can be configured and persisted using JVM custom properties as described in this example. 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.

We can adjust the Memory leak policy settings 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. The following script provides an example of how to administer the memory leak policy using wsadmin jacl scripting :


Subtopics

  • Java virtual machine custom properties