From: Amit Jain on
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 versoin 10.2.0.4 (for oracle we found one path 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.
From: Lew on
On 05/28/2010 07:39 AM, Amit Jain wrote:
> 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

So what's loading classes and not collecting them?

> 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
....
> we are using
> Oracle BEA Weblogic 9.2 MP3
> JDK 1.5.12
> Oracle versoin 10.2.0.4 (for oracle we found one path which is needed
> to applied to avoid XA transaction memory leaks).
> But we are stuck to resolve SUN, BEA Weblgogic and Apache leaks.

What makes you think those well-established products are responsible for the
leaks and not the application code?

Does that obsolete version of Java support perm-gen sweeping for GC?

--
Lew
From: Amit Jain on
hi Lew,

What makes you think those well-established products are responsible
for the
leaks and not the application code?
:) yes you are right. How can we identify fault in our Application
code. Histogram is showing classes of Apache, BEA and Oracle.

Does that obsolete version of Java support perm-gen sweeping for GC?
could you please us more view on this point...

Thanks Lew...

regrds, Amit J.
From: Lew on
On 05/28/2010 10:14 AM,
Lew wrote:
>> What makes you think those well-established products are responsible
>> for the leaks and not the application code?

By convention we cite the author of a quoted Usenet post and set the quoted
material off with various depths of consecutive right-angle-bracket ('>')
characters.

Amit Jain wrote:
> :) yes you are right. How can we identify fault in our Application
> code. Histogram is showing classes of Apache, BEA and Oracle.

Histogram from where?

Servers like WebSphere Application Server have options to help track memory
leaks, like Tivoli ITCAM.

We penurious students of the art need less expensive alternatives. The
"-verbose:gc" option to the JVM might help, as might the Java Console.

There are several standard tools for troubleshooting memory usage, starting
with "-verbose:gc", jhat and jmap through JConsole and on to Java VisualVM
<http://java.sun.com/javase/6/docs/technotes/guides/visualvm/index.html>
which last, alas for you, only came out full time with Java 6. You might be
able to use it under Java 6 to debug your Java 5 program, though.

Most of the available tools require deciphering and interpreting log files. See
<http://java.sun.com/javase/6/docs/technotes/tools/index.html#troubleshoot>
and following paragraphs.

Lew wrote:
>> Does that obsolete version of Java support perm-gen sweeping for GC?

Amit Jain wrote:
> could you please us more view on this point...

There is an option to the Sun JVM, "-XX:+CMSClassUnloadingEnabled", that
allows GC to unload unused classes after a while, and another,
"-XX:+CMSPermGenSweepingEnabled", that allows GC to clean up the permanent
generation.

To assist your analysis, "-XX:PermSize=??m XX:MaxPermSize=???m" let you
control the size of the permanent generation. I run NetBeans with a
"MaxPermSize=200m", and with all it controls, including Tomcat, that seems to
work so far.

I don't know if these options are available with Java 5 either, but you can
run your Java 5 apps on a Java 6 JVM and use these tools to help you diagnose
things.

--
Lew
From: Amit Jain on
On May 29, 1:04 am, Lew <no...(a)lewscanon.com> wrote:
> On 05/28/2010 10:14 AM,
>
> Lew wrote:
> >> What makes you think those well-established products are responsible
> >> for the leaks and not the application code?
>
> By convention we cite the author of a quoted Usenet post and set the quoted
> material off with various depths of consecutive right-angle-bracket ('>')
> characters.
>
> Amit Jain wrote:
> > :) yes you are right. How can we identify fault in our Application
> > code. Histogram is showing classes of Apache, BEA and Oracle.
>
> Histogram from where?
>
> Servers like WebSphere Application Server have options to help track memory
> leaks, like Tivoli ITCAM.
>
> We penurious students of the art need less expensive alternatives.  The
> "-verbose:gc" option to the JVM might help, as might the Java Console.
>
> There are several standard tools for troubleshooting memory usage, starting
> with "-verbose:gc", jhat and jmap through JConsole and on to Java VisualVM
> <http://java.sun.com/javase/6/docs/technotes/guides/visualvm/index.html>
> which last, alas for you, only came out full time with Java 6.  You might be
> able to use it under Java 6 to debug your Java 5 program, though.
>
> Most of the available tools require deciphering and interpreting log files.  See
> <http://java.sun.com/javase/6/docs/technotes/tools/index.html#troubles...>
> and following paragraphs.
>
> Lew wrote:
> >> Does that obsolete version of Java support perm-gen sweeping for GC?
> Amit Jain wrote:
> > could you please us more view on this point...
>
> There is an option to the Sun JVM, "-XX:+CMSClassUnloadingEnabled", that
> allows GC to unload unused classes after a while, and another,
> "-XX:+CMSPermGenSweepingEnabled", that allows GC to clean up the permanent
> generation.
>
> To assist your analysis, "-XX:PermSize=??m XX:MaxPermSize=???m" let you
> control the size of the permanent generation.  I run NetBeans with a
> "MaxPermSize=200m", and with all it controls, including Tomcat, that seems to
> work so far.
>
> I don't know if these options are available with Java 5 either, but you can
> run your Java 5 apps on a Java 6 JVM and use these tools to help you diagnose
> things.
>
> --
> Lew

Thanks Lew for your valuable inputs.

regards, Amit J.