tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <>
Subject Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
Date Fri, 12 Apr 2013 02:38:28 GMT

My apologies for late response; just realized earlier this afternoon that I
didn't respond.

On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz <> wrote:

> Hash: SHA256
> Howard,
> On 4/3/13 4:15 PM, Howard W. Smith, Jr. wrote:
> > On Tue, Apr 2, 2013 at 5:12 PM, Christopher Schultz <
> >> wrote:
> >
> >> If you don't re-deploy your webapp, then daily rolling Tomcat
> >> restarts are not necessary. I wonder why you are re-deploying
> >> your web application so many times?
> >
> > As a new tomcat user and still somewhat junior java/jsf developer,
> > I restart tomcat whenever I have new software changes to
> > deploy-and-want-to-run-on the production server. sometimes, I
> > deploy-and-restart multiple times per day, but sometimes, I'm able
> > to let tomcat/tomee run for days without restart.
> That's not really conducive to high-availability. Are you using
> Tomcat's parallel-deployment feature?

Agreed, and not using parallel-deployment feature at the moment.

> >> We run several Tomcats in parallel with modest heaps (less than
> >> 512MiB each) and they can run for months before we stop them for
> >> upgrades. It *is* possible to run JVMs without running out of
> >> memory...
> >
> >
> > I too, have not experienced any OOME, and recently, per what I
> > have seen-and-read of other (more senior java developers than
> > myself), I have decreased memory settings in my java options on
> > tomcat7w.exe (see below).
> >
> > -Xmx1024m -XX:MaxPermSize=384m -XX:+UseTLAB
> > -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
> Your heap settings should be tailored to your environment and usage
> scenarios.

Interesting. I suppose 'your environment' means memory available, operating
system, hardware. Usage scenarios? hmmm... please clarify with a brief
example, thanks. :)

heap settings tailored to 'my' environment and usage... hmmm, not many
users hitting the app, app is not used 'all day long', app has @Schedule
tasks that connects to an email acct, downloads  customer email requests,
and inserts customer requests into database (Martin recommended to close
resources; sometime ago, I had to refactor all of that code, and I am
closing the connection to the email acct, and open the connection when
@Schedule tasks are executed), i am using JMS via TomEE/activeMQ to perform
some tasks, asynchronously (tomee committers told me that use of
@Asynchronous would be better, and less overhead); honestly, I do open 2 or
3 JMS resources/queues in @ApplicationScoped @PostConstruct (if I'm not
mistaking) and close those resources in @ApplicationScoped @PreDestroy;
why? I think I read on ActiveMQ site/documentation, where they recommend
that that is better on performance, than open/close-on-demand.

Almost I mentioned in another thread, as enduser changes data,
I have an implementation that keeps google calendar in sync with the
database, which involves JMS/ActiveMQ/MDB and many/multiple requests to
google calendar API.

hmmm, more about usage, I have the following:

<Resource id="jdbc/...." type="javax.sql.DataSource">
  JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
  JdbcUrl jdbc:derby:....;create=true
  UserName ....
  Password ....
  JtaManaged true
  jmxEnabled true
  InitialSize 2
  MaxActive 80
  MaxIdle 20
  MaxWait 10000
  minIdle 10
  suspectTimeout 60
  removeAbandoned true
  removeAbandonedTimeout 180
  timeBetweenEvictionRunsMillis 30000

> You can find "conventional wisdom" that recommends pretty
> much any heap configuration you want. The only thing that I can
> consistently recommend to anyone is to set -Xms and -Xmx to the same
> value, since on a server you're pretty much guaranteed to get to -Xmx
> pretty quickly, anwyay. You may as well not thrash the heap space(s)
> getting there.

Interesting, I did set -Xms and -Xmx to the same value (as you and
others-on-this-list have recommended, thanks).

> > My Windows 2008 R2 Server (64bit 32GB RAM) never seems to get
> > higher than 1% CPU, and I think I do have memory leaks somewhere in
> > the app, but FWIW (in heap dump in java visual vm), the memory
> > leaks seem to be tomee leaks. In Java Visual VM, I do see the
> > memory grow over time, as the app is used (without a tomcat restart
> > or re-deploy of app and then restart tomcat), but I still have not
> > seen OOME...'yet'.
> What does your heap usage graph look like? It should be a nice
> sawtooth-looking thing, like this:
> /|/|/|/|/|/|/|/|/|
I do occasionally see the sawtooth-looking graph,

> You'll see that the small sawtooth pattern grows in basis over time
> and then there is a major GC which will reset you back to some
> baseline, then the process starts over again.

and eventually, I see the graph even out (non-sawtooth-looking graph).

> If you never get OOMEs, why do you think you have memory leaks?

remember, I do restart tomee quite often, especially when I have software
updates to deploy to/on the server. It's been a while, since I let it run a
few days without stop-deploy-start. I am looking forward to letting it be
and running without touching it, so I can see if it results in an OOME or
reaches the peak.

> that TomEE does?

I would rather take the blame. My first year of developing the JSF web app,
I was all into xhtml pages and Java, now I am more in the Java side of
things and  performance performance performance, especially since I'm using
tomcat (via tomee) and listening in on many topics on this tomcat user list
(and learning and trying to apply this/that).

I'm already spreading the word to others how helpful you all are and how
I'm learning a bit more...outside of JSF world. :)

> - -chris
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> BSipr2ScOQ2DJNNBjwWAth9AqbzC/nKX4fNlqKCSqWmpZf3JyFChFi/nQJajZQRR
> 3EJEYLXP3YBRPfixRZLrcUw9rrVLs/+apFL4XZCdgkFvrPto201E9ef99ns7Ya+g
> oBWr51g8Fkx5jeztRmzg+H/8+KVICuHUVXTCBQtuybwTfCyWKFwZs5lfmKiX7oKC
> 1ts7S6mIhzpFjO+KFxnFWZkM4ch7SADqCe5WhxnOYpjaz7p7d2XGv1iamjsGVKF2
> FE1bZvOiyEFga6vlh1TpAFmAnOmHmkHtxNAG6eSLeOfYkxKAqSy4z5O6leoP/tUc
> Vri2+GIxwyxyUYprTnvQW7S1UTQF6t658itnZXLrnvRr8Oj/7tzmFcScDvajbYUx
> P8tECk7SENg0Sr6T8tY3VjR+A1c1u8i5k9iLDayVE8zxcDvCA6n2cVmtj/5K3xwe
> MNWhsr6kfca9q7CU5fIe38ebrsw8+UU4J2TkrtHYUpc9uC1AxXmLcC8LEXCV/IiZ
> pIHVlIj2VztPODHfpQvPVUH7VkQKu0M3WbeR+OTQDJJs8X7MLou+YFao+3ri0x9/
> 09i6VS+AC8E8zqQcl0KNeBJf7kuTKP/lguLcCRby0YC2YuppwHaBcRiECKy1UDZR
> FB/X9VbiGKGt95lZvZae
> =X3iQ
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message