1. No there is no Garbage Collection configuration in tomcat. This is controlled by the JVM.
2. This is not possible. Garbage collection is kicked off when a pool in the JVM fills up and clears up all expired objects. For there to be a memory leak then there must be something keeping a handle on the objects. 3. No, see answer to 2. In your case it does sound like it's the 3rd party app that is causing the "memory leak". You can get a java profiler and see which objects are being held on to and here's a couple of links to some garbage collection pages to help you understand it better. http://java.sun.com/developer/technicalArticles/Programming/turbo/ http://java.sun.com/docs/hotspot/gc1.4.2/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 20 October 2004 07:14 To: [EMAIL PROTECTED] Subject: Garbage Collection configuration and Memory Leakage Hi, all We have deployed a third party web application in tomcat which translates HTTP requests from web clients into CORBA commands. We are seeing large increases in memory which never seems to be released. The memory sizes are checked every day with the "ps -o time,etime,pcpu,pmem,vsize,rssize" command. The third party suggests that the problems could be due to garbage collection configuration in tomcat and would like us first to consult with 'tomcat experts'. If you have expertise with tomcat and are reading this could you please confirm for us: 1. Is there any garbage collection configuration in tomcat? 2. If the answer to 1. is yes, is it possible that the garbage collection configuration in tomcat could be causing a large amount of memory never to be released? 3. Is it possible that the garbage collection configuration in the JVM could be causing a large amount of memory never to be released? The implementation details are Tru64 Unix, tomcat 5.0.19, SDK 1.4.1-1 (for Tru64 Unix from HP). We are aware of other memory leak issues reported in tomcat 5.0.19 and SDK 1.4.1-1 but we have been able to rule out these known problems as the cause of our memory leak. Thanks Kenny
Any opinions expressed in this E-mail may be those of the individual and not necessarily the company. This E-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this E-mail in error and that any use or copying is strictly prohibited. If you have received this E-mail in error please notify the beCogent postmaster at [EMAIL PROTECTED] Unless expressly stated, opinions in this email are those of the individual sender and not beCogent Ltd. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
