Noel J. Bergman wrote: > Stefano Bagnara wrote: > >> I tried reproducing Noel issue a lot of times. I ran profilers and I ran >> postage with a lot of configurations but I have not found any leak. > >> Imo the issue is invalid and closed as cannot reproduce until we get >> much more informations. > > The memory leak is documented and consistent. The fact that you cannot > reproduce it is good, since perhaps it won't effect too many others, but > does not mean that it doesn't exist. The empirical data doesn't lie: every > day, there is ~2MB less memory available on the heap, which is consistent > with what I have been seeing since I first reported the problem.
I don't say that James has no memory leaks. I simply say that GC does not guarantee to garbage every unreferenced object. GC in modern JVM is much more complicate and the JVM doesn't even ensure you that a GC will ever occour when you call Runtime.gc() method. >> The fact that Noel's production server does not work with an updated >> JVM (1.4.2 09=>12) is already weird enough to be considered a special >> case where maybe the JVM has problems and not James itself. > > So we only support JAMES for JVMs that are the latest? Have you looked at > the fixes between _09 and _12 to see if any are meaningful? I'll note that > running JDK 1.4.2_12 caused problems with thread deadlocks when profiling, > since I did actually try it (as well as JDK 1.5.0_06). I didn't say this. I say that is weird that your system works with 1.4.2_09 and not with 1.4.2_12 or 1.5.0_08: you know that Sun put much more attention than US in compatibility between versions. So I wonder what does your system have so special to change behaviour (worse) upgrading a minor release for 1.4.2_09 to 1.4.2_12. And I don't know what's the point in reading the changelog: I don't expect to read "we introduced new deadlocks" for the 1.4.2_12 release notes against the previous one, but only to read fixes. Imho is *really* weird that you have to use 1.4.2_09 because newer versions do not work for you. This is not to mean that I expect James to have the same behaviour in all the JVMs. I tested 1.4.2_09, 1.4.2_10, 1.4.2_12, 1.5.0_6 and 1.5.0_8 with no specific problems . >> This is not a question of a pathetic leak: this is a question of >> reproducible leak. > > Reproducible: ~2MB per day, consistently, over a long period of time. It > explains why I have consistently been able to keep JAMES running for only 10 > days at a time. What's the key to reproducibility? You said that the traffic is not important.. I don't understand how you understood this. You proposed the log rotation issue: I did a lot of tests to try it and demostrate we are on the bad side of our search. >> now we don't even know if this bug exists at all. I already questioned >> the "confirmed" word used by Noel. Imho a bug is confirmed when I can >> reproduce it in a clear way, and memstat is not a index for this. > > I'm sorry, but the empirical data is not subject to your dispute, and the > existence of the OutOfMemoryError exception is not subject to your personal > desires. The existence of an OOM does not automatically identify a leak. The fact that I'm working hard to try to understand your scenario and try to set up tests to reproduce it demonstrate my willing to find a solution and my trust in you. Otherwise I would have ignored you completely because I normally close issues with not enought informations to allow us to reproduce. >> So until Noel won't decide to use a real profiler (with per-instance >> allocation time tracking) and not hprof :-P > > hprof shows is which allocation sites are instantiating objects that are not > being collected. And I'm trying to get real-world runs in production data, > and not toy tests in a controlled environment. Real-world testing may be > messy, but your tests do not exercise dnsjava at all, for example. I never said that my tests are complete. What scare me is that using hprof we still don't know if we have to look in phoenix logs, in dnsjava, in mysql connector, or somewhere else.. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
