> -----Original Message----- > From: Luciano Andress Martini [mailto:777u...@gmail.com] > Sent: Monday, January 30, 2012 10:34 AM > To: Tomcat Users List > Subject: Re: Java.lang.out.of.memory not clearly.... > > 2012/1/30, Luciano Andress Martini <777u...@gmail.com>: > > Pid i changed the configuration, like this: > > > > JAVA_OPTS="-Djava.awt.headless=true -Xmx1512m -XX:ParallelGCThreads=4 > > -XX:+UseParNewGC -XX:MaxPermSize=1024M -XX:+UseConcMarkSweepGC > > -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" > > > > The system is 64 bits + Java 64 bits, running in debian > > paravirtualized with Xen. > > > > > > 2012/1/30, David kerber <dcker...@verizon.net>: > >> On 1/30/2012 11:05 AM, Luciano Andress Martini wrote: > >>> 2012/1/30, Caldarale, Charles R<chuck.caldar...@unisys.com>: > >>>>> From: Luciano Andress Martini [mailto:777u...@gmail.com] > >>>>> Subject: Re: Java.lang.out.of.memory not clearly.... > >>>> > >>>>> Jeffrey im sorry, but i need to ask, my boss says that is > impossible > >>>>> to be a problem in the software cause java unalocate objects > >>>>> automatically, is that true? > >>>> > >>>> A) Stop your top posting - it's incredibly annoying and makes > people > >>>> much > >>>> less likely to help. > >>>> > >>>> B) Your boss is wrong. Google for many examples of memory leaks > in > >>>> Java. > >>>> > >>>> - Chuck > >>>> > >>>> > >>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > >>>> PROPRIETARY > >>>> MATERIAL and is thus for use only by the intended recipient. If > you > >>>> received > >>>> this in error, please contact the sender and delete the e-mail and > its > >>>> attachments from all computers. > >>>> > >>>> > >>>> ------------------------------------------------------------------ > --- > >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>> > >>>> > >>> > >>> Thank you and sorry Chuck. > >>> Jeffrey what is your opinion about this? > >>> The development team is using a software that "Draw" java code > called > >>> developer, and do not programming in. Im a assembler/C programmer > and > >>> don't have so much knowing about java. > >> > >> Java can have memory leaks just as easily as C can, but if the app > is > >> standalone, it will release them when the app closes and the JRE > shuts > >> down. > >> > >> I have killed tomcat more than once with memory leaks, so it's easy > to > >> do. I'm not the expert that Chuck and Mark T are, but here is my > >> understanding of what happens: if the app is running under tomcat, > the > >> JRE never shuts down since tomcat is using it. That means the JRE > can > >> not free up memory that your app has left allocated, as it would be > able > >> to in a standalone app. So your Tomcat app has to clean up after > itself > >> because there is nothing else that can do so. > >> > >> > >>> > >>> But all the fault is falling back to me in the company. > >> > >> I know the feeling :-/ > >> > >> > >> > >> -------------------------------------------------------------------- > - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > Sorry the gmail is doing wrong with my messages =/ > > I changed the configuration like this: > JAVA_OPTS="-Djava.awt.headless=true -Xmx1512m -XX:ParallelGCThreads=4 > -XX:+UseParNewGC -XX:MaxPermSize=1024M -XX:+UseConcMarkSweepGC > -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" >
Luciano - Sorry for opening a can of worms and disappearing, but I had to sit through a long meeting (aka useless). I didn't say you definitely had a leak, but that it sounded typical of one. It could just be that your memory allocation was undersized for the app(s) you are running. Let it run a few days -- through a few more iterations of the "big job" -- and see if the OOM raises its ugly head again. IF it doesn't you are probably fine. Since you are running a 64-bit system, you have plenty of room to grow that -Xmx parameter if you need to. I'd like to suggest you go back and re-read the Sun docs on Java memory parameters and maybe look into enabling JMX in Tomcat and using JConsole to actually watch the memory allocation cycles for a bit. It is a useful tool, among many, for seeing if you've allocated memory correctly (you may find that 1Gig is way too big for your permgen). As a fellow SA, I can sympathize with your predicament. I run into the same attitudes regularly. I once got almost the exact same response from my lead developer (at the time) when I asked about memory leaks. Since you know assembler & C, when Java creates a new Object or variable it does the equivalent of a malloc() for the memory to hold the data. There is no equivalent of a free() call, though setting the object to null is as close as it gets (other "real" java developers can correct this if they have to). If the object wasn't created as a static object or assigned to a static object, when the function it was created in exits, the object is marked for garbage collection (de-referenced) by the run machine. That is the automatic bit that your boss mentioned. So you can see, there are some points at which it could be quite easy for a programmer to insert a memory leak if he's not paying close attention. <opinion> From your description of the developer tools, it sounds like they are using a code generator to create the Java code. In over 25 years of IT work, from both sides, I've yet to see a code generate that was "perfect". I always take what they generate with a grain of salt. Back in the really old days, code generators were only good as a starting point. Only use them if someone is available to review the code they generate occasionally. (I suspect libraries until proven, also.) </opinion> Finally, If you are using Tomcat 6.x or 7.x, check your Tomcat logs after an orderly shutdown or undeploy/redeploy. If you have left the JreMemoryLeakPreventionListener in the server.xml, then it is possible that Tomcat itself might point out some leaked objects. So far for me, it has only pointed out left over database driver implementations that my developers haven't de-registered. Someone else on this list can probably tell you if it is helpful for simple object leaks. Jeff __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
