tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Janner <>
Subject RE: Java.lang.out.of.memory not clearly....
Date Mon, 30 Jan 2012 18:22:36 GMT
> -----Original Message-----
> From: Luciano Andress Martini []
> 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 <>:
> > 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 <>:
> >> On 1/30/2012 11:05 AM, Luciano Andress Martini wrote:
> >>> 2012/1/30, Caldarale, Charles R<>:
> >>>>> From: Luciano Andress Martini []
> >>>>> 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
> >>>>
> >>>>
> >>>> 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:
> >>>> For additional commands, e-mail:
> >>>>
> >>>>
> >>>
> >>> 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:
> >> For additional commands, e-mail:
> >>
> >>
> >
> 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.

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.)

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.


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:
For additional commands, e-mail:

View raw message