Need Help getting OOME.

[abhi_jboss]

Hi ALL,

Currently we are using Jboss 5.1.0 in our production environment and using heap dump I can see many threads are occupying memmory in heap. Due to which we are getting OOME. here is the stack trace of the thread that is consuming 41% of the heap.

java.lang.Object

java.lang.Thread

sun.misc.GC$Daemon

org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlMonitorTimerTask$1

net.sf.ehcache.CacheManager$1

org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread

org.quartz.core.QuartzSchedulerThread

org.apache.log4j.helpers.FileWatchdog

org.apache.log4j.PropertyWatchdog

org.apache.log4j.xml.XMLWatchdog

java.lang.ref.Finalizer$FinalizerThread

sun.awt.image.ImageFetcher

com.ibm.icu.impl.ICUNotifier$NotifyThread

com.arjuna.ats.internal.arjuna.recovery.Connection

com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor

org.springframework.context.support.AbstractApplicationContext$1

com.mchange.v2.resourcepool.BasicResourcePool$5

com.arjuna.ats.internal.arjuna.coordinator.ReaperThread

com.arjuna.ats.arjuna.coordinator.TxControl$Shutdown

com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread

org.jboss.remoting.transport.socket.SocketServerInvoker$AcceptThread

org.jboss.util.timeout.TimeoutFactory$1

java.lang.ref.Reference$ReferenceHandler

org.jboss.console.plugins.AOPLister$RefreshPoller

org.eclipse.core.internal.jobs.InternalWorker

java.util.TimerThread

com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread

org.eclipse.core.internal.jobs.Worker

java.util.logging.LogManager$Cleaner

net.sf.ehcache.store.DiskStore$SpoolAndExpiryThread

org.eclipse.osgi.framework.eventmgr.EventManager$EventThread

org.jboss.bootstrap.AbstractServerImpl$LifeThread

com.arjuna.ats.internal.arjuna.recovery.Listener

org.apache.catalina.startup.Catalina$CatalinaShutdownHook

org.jboss.bootstrap.AbstractServerImpl$ShutdownHook

org.quartz.simpl.SimpleThreadPool$WorkerThread

org.jboss.remoting.transport.socket.SocketServerInvoker$ServerSocketRefresh

com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery

org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread

Regards,

Abhijeet

[wdfink]

Hello Abhijeet,

welcome to the forum.

Finding OOM will be a difficult thing. You might use a profiler or JVM tool to analyze the heap dump and find out what kind of objects are fill the heap and get not freed.

Often it is a Collection which hold unwanted references. A root cause will be (i.e.) to have a StatelessSessionBean which include a collection as instance- or static variable (which is not according to the spec btw)

If you see the problem periodically you might find the use-case and use a test environment with a profiler to see what objects are increased by-call.

good luck

[abhi_jboss]

Thanks Fink,

However I checked it and found out that it might be causing due to the heavy load on Jboss Scheduler Varia. In this we have implemented a class and there are so many scedulers are configured for the same class.

Please let me know if that is the case. Does schedulers in jboss has impact on memory footprint.

Regards,

Abhijeet

[wdfink]

Not sure, but I suppose not.

The scheduler itselve should not have a big footprint.

I suppose there is more from application side.

You need to check which objects are use big amount of heap and whether all point to the same root-reference.

[abhi_jboss]

thanks Fink, your answer helped me and made me review the code once more to check for any possible memory leak code blocks and luckily I found one.