Memory Leak Issue in Weblogic, SUN, Apache and Oracle classes Options

Question

Hi All,

Please find below the description of memory leaks issues.

1. Statistics show major growth in the perm area (static classes). Flows were ran for 8 hours , Heap dump was taken after 2 hours and at the end. A growth in Perm area was identified

2. Statistics show from our last run 240MB growth in 6 hour,40mb growth every hour 2GB heap –can hold ¾ days ,heap will be full in ¾ days Heap dump show –growth in area as mentioned below

JMS connection/session Area

Apache

• org.apache.xml.dtm.DTM[]
• org.apache.xml.dtm.ref.ExpandedNameTable$ExtendedType
• org.jdom.AttributeList
• org.jdom.Content[]
• org.jdom.ContentList
• org.jdom.Element

SUN

• ConstantPoolCacheKlass
• ConstantPoolKlass
• ConstMethodKlass
• MethodDataKlass
• MethodKlass
• SymbolKlass
• byte[]
• char[]
• com.sun.org.apache.xml.internal.dtm.DTM[]
• com.sun.org.apache.xml.internal.dtm.ref.ExtendedType
• java.beans.PropertyDescriptor
• java.lang.Class
• java.lang.Long
• java.lang.ref.WeakReference
• java.lang.ref.SoftReference
• java.lang.String
• java.text.Format[]
• java.util.concurrent.ConcurrentHashMap$Segment
• java.util.LinkedList$Entry

Weblogic

• com.bea.console.cvo.ConsoleValueObject$PropertyInfo
• com.bea.jsptools.tree.TreeNode
• com.bea.netuix.servlets.controls.content.StrutsContent
• com.bea.netuix.servlets.controls.layout.FlowLayout
• com.bea.netuix.servlets.controls.layout.GridLayout
• com.bea.netuix.servlets.controls.layout.Placeholder
• com.bea.netuix.servlets.controls.page.Book
• com.bea.netuix.servlets.controls.window.Window[]
• com.bea.netuix.servlets.controls.window.WindowMode
• javax.management.modelmbean.ModelMBeanAttributeInfo
• weblogic.apache.xerces.parsers.SecurityConfiguration
• weblogic.apache.xerces.util.AugmentationsImpl
• weblogic.apache.xerces.util.AugmentationsImpl$SmallContainer
• weblogic.apache.xerces.util.SymbolTable$Entry
• weblogic.apache.xerces.util.XMLAttributesImpl$Attribute
• weblogic.apache.xerces.xni.QName
• weblogic.apache.xerces.xni.QName[]
• weblogic.ejb.container.cache.CacheKey
• weblogic.ejb20.manager.SimpleKey
• weblogic.jdbc.common.internal.ConnectionEnv
• weblogic.jdbc.common.internal.StatementCacheKey
• weblogic.jms.common.Item
• weblogic.jms.common.JMSID
• weblogic.jms.frontend.FEConnection
• weblogic.logging.MessageLogger$1
• weblogic.logging.WLLogRecord
• weblogic.rjvm.BubblingAbbrever$BubblingAbbreverEntry
• weblogic.rjvm.ClassTableEntry
• weblogic.rjvm.JVMID
• weblogic.rmi.cluster.ClusterableRemoteRef
• weblogic.rmi.internal.CollocatedRemoteRef
• weblogic.rmi.internal.PhantomRef
• weblogic.rmi.spi.ServiceContext[]
• weblogic.security.acl.internal.AuthenticatedSubject
• weblogic.security.acl.internal.AuthenticatedSubject$SealableSet
• weblogic.servlet.internal.ServletRuntimeMBeanImpl
• weblogic.transaction.internal.XidImpl
• weblogic.utils.collections.ConcurrentHashMap$Entry

Oracle XA Transaction

• oracle.jdbc.driver.Binder[]
• oracle.jdbc.driver.OracleDatabaseMetaData
• oracle.jdbc.driver.T4C7Ocommoncall
• oracle.jdbc.driver.T4C7Oversion
• oracle.jdbc.driver.T4C8Oall
• oracle.jdbc.driver.T4C8Oclose
• oracle.jdbc.driver.T4C8TTIBfile
• oracle.jdbc.driver.T4C8TTIBlob
• oracle.jdbc.driver.T4C8TTIClob
• oracle.jdbc.driver.T4C8TTIdty
• oracle.jdbc.driver.T4C8TTILobd
• oracle.jdbc.driver.T4C8TTIpro
• oracle.jdbc.driver.T4C8TTIrxh
• oracle.jdbc.driver.T4C8TTIuds
• oracle.jdbc.driver.T4CCallableStatement
• oracle.jdbc.driver.T4CClobAccessor
• oracle.jdbc.driver.T4CConnection
• oracle.jdbc.driver.T4CMAREngine
• oracle.jdbc.driver.T4CNumberAccessor
• oracle.jdbc.driver.T4CPreparedStatement
• oracle.jdbc.driver.T4CTTIdcb
• oracle.jdbc.driver.T4CTTIk2rpc
• oracle.jdbc.driver.T4CTTIoac
• oracle.jdbc.driver.T4CTTIoac[]
• oracle.jdbc.driver.T4CTTIoauthenticate
• oracle.jdbc.driver.T4CTTIokeyval
• oracle.jdbc.driver.T4CTTIoscid
• oracle.jdbc.driver.T4CTTIoses
• oracle.jdbc.driver.T4CTTIOtxen
• oracle.jdbc.driver.T4CTTIOtxse
• oracle.jdbc.driver.T4CTTIsto
• oracle.jdbc.driver.T4CXAConnection
• oracle.jdbc.driver.T4CXAResource
• oracle.jdbc.oracore.OracleTypeADT[]
• oracle.jdbc.xa.OracleXAResource$XidListEntry
• oracle.net.ano.Ano
• oracle.net.ns.ClientProfile
• oracle.net.ns.ClientProfile
• oracle.net.ns.NetInputStream
• oracle.net.ns.NetOutputStream
• oracle.net.ns.SessionAtts
• oracle.net.nt.ConnOption
• oracle.net.nt.ConnStrategy
• oracle.net.resolver.AddrResolution
• oracle.sql.CharacterSet1Byte

We are using - Oracle BEA Weblogic 9.2 MP3 - JDK 1.5.12 - Oracle version 10.2.0.4

For Oracle we found one patch which is needed to applied to avoid XA transaction memory leaks. But we are stuck to resolve SUN, BEA Weblgogic and Apache leaks.

please suggest...

regards, Amit J.

Answer 1

Here is Sun page on troubleshooting memory leaks. Section 3.3 lists a number of techniques for figuring out where a leak is occurring.

Any answers saying where the leak might be based on the dump, what you are running, etc are likely to be pure guesswork. Your best bet is to try and track the leak(s) down yourself.

Answer 2

To determine that your application is not the cause of the issue, deploy it on another open source server (jboss etc) and re-run the load test scenario. If the problem persists then you need to look into your implementations in your app.

In your app, you then need to isolate specific transactions and their nature that is causing the leak. Often it is seen that one specific transaction or operation initiates the behavior - Isolating to that level - assists in focusing in the core issue. For this, you can add trackers to each of operations that are involving xa transaction or dealing with heavy memory usage due to multiple object creation.