Nikolaos (and all others who offered advice) I threw a bunch of solutions at this problem, including those mentioned below, so I'm not sure what fixed my problem. Probably a combination of better code and better system software. I did notice a big improvement when I upgraded my java to 1.4.2, so no doubt the StringBuffer issue was a big part of the picture.
I'm still learning to use OptimizeIt, but this turned out to be a great tool as well. Thanks to all!! Bill Bill Tantzen University of Minnesota Libraries [EMAIL PROTECTED] 612-626-9949 (office) 612-250-6125 (cell) ________________________________________________________________ I guess the man's a genius, but what a dirty mind he has, hasn't he? -- Nora Joyce --> -----Original Message----- --> From: Nikolaos Giannopoulos [mailto:[EMAIL PROTECTED] --> Sent: Tuesday, October 21, 2003 10:23 AM --> To: Tomcat Users List --> Subject: RE: application eats up memory --> --> --> Bill, --> --> Java 1.4.0 has a known StringBuffer memory leak. --> --> Java 1.4.0 + XML parsing will "eat" memory because of heavy string --> manipulation done in XML parsing (in conjunction with this --> memory leak of --> course). --> --> I would recommend that you at least use 1.4.2 (as we have --> found other --> stability issues with 1.4.0 and 1.4.1 on Solaris). --> --> If you do try this - please let us know if it works! --> --> HTH, --> --> --Nikolaos --> --> --> > -----Original Message----- --> > From: Bill Tantzen [mailto:[EMAIL PROTECTED] --> > Sent: Tuesday, October 21, 2003 9:18 AM --> > To: Tomcat Users List --> > Subject: Re: application eats up memory --> > --> > --> > --> > On Tuesday, October 21, 2003, at 08:05 AM, Shapira, Yoav wrote: --> > --> > > --> > > Howdy, --> > > --> > >> I'm having a problem with a particular application --> that grows and --> > >> grows --> > >> in size until the jvm runs out of memory, and tomcat --> shuts down. I am --> > >> on a box with 1GB of memory and 350MB+ of swap. I --> have tried various --> > >> settings in my catalina.sh, which just seem to make --> the app crash even --> > >> quicker. I suspect that the problem lies in my code, --> but I don't know --> > >> exactly where to start looking. --> > > --> > > One possibility is to use a profiler, such as --> OptimizeIt or JProbe, --> > > which shows you memory differences on the heap between --> two instances of --> > > time. You'll be able to see what has been allocated, --> and where it's --> > > referenced. --> > --> > Any recommendations here? They are a little pricy, and I --> would want to --> > make sure I'm getting bang for my $$ --> > --> > > As you know, it's not easy to create outright memory --> leaks in java. --> > > The --> > > garbage collector will collect objects that are no --> longer referenced by --> > > anything, and return their memory to the heap. So you --> should make sure --> > > you're not keeping references to objects you don't --> need. One likely --> > > place for this to happen is in class (static) variables. --> > --> > I will check this out. I do have some... --> > --> > > What JVM settings have you tried, and with what results? --> > --> > various combinations (and numbers) of the following with --> the result --> > that the tomcat shuts down rather quickly, or fails to --> start at all due --> > to lack of memory. (tomcat and apache are the only things --> running on --> > this box). --> > --> > ## CATALINA_OPTS="-Djava.awt.headless=true -Xmx256m" --> > ## CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=64m --> -XX:MaxNewSize=64m" --> > ## -Xms128m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m --> > ## JAVA_OPTS="-server" --> > --> > --> > > --> > >> constructs cause memory to leak in java? I have some --> listener classes --> > >> in my app. Are they a problem? Sessions? Database --> connections (no --> > >> pooling)? Any of these things red flags? --> > > --> > > Be careful with listener classes to not hold on to --> unneeded references. --> > > For example, if you have a session listener, and you --> add each session --> > > to --> > > some map or list on the session's creation, make sure --> to remove it from --> > > your map or list when it's destroyed. You have to --> listen to both --> > > events. If you don't remove it, you keep a reference --> to it, it will --> > > stay in memory, and that's a memory leak. --> > > --> > >> tomcat 4.1.18, classes12.jar (from oracle), and --> xmlparserv2.jar (also --> > >> oracle) --> > >> java version 1.4.0_00 --> > >> solaris 9 (SunOS 5.9) --> > > --> > > Upgrade to JDK 1.4.2 if you can. Upgrade to tomcat --> 4.1.27 if you can. --> > > And you should have a very strong reason to use --> xmlparserv2.jar from --> > > Oracle -- what is it? Why not xerces? --> > --> > I can, and will!! You guessed it, xmlparserv is a set of --> xml parsing --> > (sax and dom) tools. --> > --> > thanks much! --> > --> > --> > --> ------------------------------------------------------------ --> --------- --> > To unsubscribe, e-mail: [EMAIL PROTECTED] --> > For additional commands, e-mail: --> [EMAIL PROTECTED] --> > --> --> --> --> ------------------------------------------------------------ --> --------- --> To unsubscribe, e-mail: [EMAIL PROTECTED] --> For additional commands, e-mail: [EMAIL PROTECTED] --> --> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
