>I meant filters defined in web.xml, not scriptlets. It's /possible/ that >your <bean:> tags are using a whole lot of memory, but probably not >(you'd have to be creating randomly-named session attributes over and >over, and never freeing them... I'm guessing you're not doing that).
No, I'm not doing that. They are only <bean:mesasge> tags displaying some text... There are no filters or any special contents in my web.xml. >Can you expand the "+" next to Arrays.copyOfRange to see what the rest >of the stack trace is? I'm sure that a lot of things call >Arrays.copyOfRange, so it's hard to determine what the problem is. Post >another screenshot if you can. Sure, here it is (profiler3_expanded.JPG): http://www.inf.u-szeged.hu/~michnay/profiler/ As you can see, now there are other methods as well allocating char[] objects. It's pretty confusing and very hard to track how exactly my pages are processed by the server... at least, it is for me... :) >Your code looks just fine, although I might suggest factoring-out the >code to mess with JNDI, the DataSource, etc. and just write a method >that returns a Connection (or throws an exception). You are also closing >your resources out of order (stmt first, then conn, then rst). Since >you're closing those resources in your finally block, why bother closing >them in the method body? It will be a cleaner method without this extra >stuff in there, but functionally equivalent. I'll try to factor out the JNDI parts. Should I factor out the creation of statement and result objects as well, or only the connection should be factored out? Should I create another method to free up the resources? I'm not sure what's the best way of doing this. Do you have a sample code to take a look at? >In terms of design, I would write that method to return a List of >application-specific objects instead of maintaining two separate >(untyped) lists that just happen to be related. It is a much more >understandable design and yields much more readable code. It will also >simplify your JSP loop, etc. What do you mean by "List of application-specific objects"? Is it a multi-dimensional ArrayList object? I'm very interested in creating well-readable and well-understandable code, so some samples would be appreciated :) (sorry, I'm not very experienced in Java) >Do you see any place where objects could not be freed-up? Where? I'll show you. Please take a look at profiler4.JPG found at the same URL. The big black curly bracket shows how the memory is eaten up by simle page reloads. The profiler's GC button can be found at the upper-left corner indicated by the green arrow. By pressing GC, a small amount of memory is freed up, which can be seen in the yellow ellipse. It's a little slope indicating that a very little amount of memory could be freed up, no matter how many times I press the GC button. What about the rest? That's pretty confusing and sometimes a bit annoying, because I don't see where my code wastes ~25 Mbytes of memory... >Ouch! If you reload many times, does a JVM-initiated GC fire off? You >should be able to look at the GC graph to see if the JVM is at least >attempting to to a GC. It's possible to limit your JVM so much that even >simple things cause OOMs, especially /during/ GC runs. No, it's me firing off a GC by pressing the GC button of the profiler. There are no GC calls in my code... >You mentioned you were using Tomcat as well. I'm assuming that since >you're using Java 1.6 (Sun?), you're also using Tomcat 5.x or 6.x? Oh, yes, sorry, I'm using Tomcat 5.5 (bundled with NetBeans 5.5.17), MySQL server 5.0.37, under Win XP SP2. >No problem. We'll figure it out... but it might take a while. I remember >when I first started profiling my apps. I started freaking out because I >had no idea so many objects existed. At first I thought everything was >leaking memory, and it turns out that everything was working just fine. >The GC can play lots of tricks on you if you don't fully understand what >you're seeing. Yes, you're absolutely right, that's exactly what I think. I was about to accept that I'm just simply unable to comprehend what happen behind the scenes, but now - thanks to your helpfulness and willingness to help - things are getting clearer... You just simply don't see how much you help. Apart from the fact that my code is whether wastes or doesn't waste ~25 Mbytes of memory by virtually "doing nothing", it's very calming to see that other factors not directly related to my code can affect memory load. I appreciate every bits of help. Regards, BM ----- Original Message ---- From: Christopher Schultz <[EMAIL PROTECTED]> To: Struts Users Mailing List <user@struts.apache.org> Sent: Wednesday, May 23, 2007 4:27:50 PM Subject: Re: Serious memory leak -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Balazs, Balazs Michnay wrote: > I think it's just a "small" [GC], because sometimes when I click on > it several times, it frees up a little memory... Okay, that may be one thing complicating your instrumentation. >> Every request will eat up memory, but /should/ eventually be freed. Does >> your "simple" page have any filters operating on it? > > No. There are only struts <html:...> tags and some other <bean:...> tags. > There are no scriptlets on it. I meant filters defined in web.xml, not scriptlets. It's /possible/ that your <bean:> tags are using a whole lot of memory, but probably not (you'd have to be creating randomly-named session attributes over and over, and never freeing them... I'm guessing you're not doing that). > Well, since my last post I kept > on testing other pages and discovered that char[] and byte[] objects are > piled up by other methods as well. InflaterInputStream is there, however > it doesn't allocate as much memory than others do now. That's what I figured. From your screenshots, it appears that char[] objects are slightly worse than byte[] objects. char[] objects are almost certainly allocated for String object contents. > Now it seems that (among others) java.util.Arrays.copyOfRange eats up > lots of memory. Can you expand the "+" next to Arrays.copyOfRange to see what the rest of the stack trace is? I'm sure that a lot of things call Arrays.copyOfRange, so it's hard to determine what the problem is. Post another screenshot if you can. > This might be caused by me not properly using my > database connection pool, so here's how I use and probably everything > gets clear... I think you're speculating too much... if you were abusing your db connection pool, you'd probably be running out of connections, not memory. > 1) Every time I'd like to connect to my db, I use the java code > posted everywhere, but since I want to store more than 1 row of the > resultset, I declare an ArrayList. Probably this shouldn't be done > this way, because memory is eaten up by array operations... ArrayList doesn't store char[] anywhere, unless you are storing char[] objects in your ArrayList. Also, ArrayList uses System.arraycopy to expand and re-allocate its arrays, not Arrays.copyOfRange. > Here's my code: Your code looks just fine, although I might suggest factoring-out the code to mess with JNDI, the DataSource, etc. and just write a method that returns a Connection (or throws an exception). You are also closing your resources out of order (stmt first, then conn, then rst). Since you're closing those resources in your finally block, why bother closing them in the method body? It will be a cleaner method without this extra stuff in there, but functionally equivalent. In terms of design, I would write that method to return a List of application-specific objects instead of maintaining two separate (untyped) lists that just happen to be related. It is a much more understandable design and yields much more readable code. It will also simplify your JSP loop, etc. > It this the right way to use my connection pool? Connection pool use is just fine. Some other stuff ought to be re-thought, but it shouldn't run out of memory. > If not, this might be the reason of my memory leaks, because some > objects may not be able to be freed-up... Do you see any place where objects could not be freed-up? Where? > [InflaterInputStream allocations are] now nothing compared to those > allocated by java.util.Arrays.copyOfRange method... This is much more plausible. > Each request (a reload) causes a memory allocation of another 1-3 Mbytes that > the profiler gc() won't free up. Ouch! If you reload many times, does a JVM-initiated GC fire off? You should be able to look at the GC graph to see if the JVM is at least attempting to to a GC. It's possible to limit your JVM so much that even simple things cause OOMs, especially /during/ GC runs. >> What JVM, app server, etc. versions are you using? > > I have the latest Java installed (Version 6 Update 1). You mentioned you were using Tomcat as well. I'm assuming that since you're using Java 1.6 (Sun?), you're also using Tomcat 5.x or 6.x? > Any hey, thanks so much for taking a look at my code, and helping at all, I > appreciate it. No problem. We'll figure it out... but it might take a while. I remember when I first started profiling my apps. I started freaking out because I had no idea so many objects existed. At first I thought everything was leaking memory, and it turns out that everything was working just fine. The GC can play lots of tricks on you if you don't fully understand what you're seeing. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVE9m9CaO5/Lv0PARAuhkAKCWqS8u2aApySB7m0lxilr4ucI71gCgnopa 0CiD7XyrXMB+3/VBnLK0/ug= =Sc62 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
