> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Monday, January 28, 2013 10:33 AM
> To: Tomcat Users List
> Subject: Re: Restarting Tomcat from within itself?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Daniel,
>
> On 1/28/13 8:19 AM, Daniel Mikusa wrote:
> > On Jan 26, 2013, at 5:19 AM, Sunil Shevante wrote:
> >
> >> Hi,
> >>
> >> Is it possible to restart tomcat from within itself?
> >>
FWIW, It is possible to restart tomcat by calling,
org.apache.catalina.startup.Bootstrap.main(new String[] { "stop" });
then use a shutdown hook to start it up again,
But I really don't recommend it.
> >> I host a JSP website and somehow the memory utilization keeps on
> >> increasing from time to time. I then have to manually restart
> Tomcat.
> >>
> >> While I understand that in the long term, I should focus on fixing
> >> the memory leaks, is there a way by which I can restart Tomcat after
> >> the free memory goes below a threshold percentage?
> >
> > I wouldn't try to do this inside Tomcat. With the tools provided by
> > the JVM (jmap or JMX), you can monitor just as easily from outside
> > Tomcat. Instead, create a monitoring script to watch the Tomcat
> > process. When memory usage hits a certain level, dump the heap (so
> > you can analyze your memory problem later) and restart Tomcat.
>
> +1
>
> If you want to chance it, you could set -XX:OnOutOfMemoryError=<cmd>
> and write a script that tries to dump your heap (or just have the JVM
> do that for you) and then bounce Tomcat.
>
> Note that not all OOMEs are life-threatening for the JVM.
>
> I have experienced two kinds of OOMEs:
>
> 1) Truly out of memory: your app simply needs more heap. In these
> cases, the JVM generally goes into GC panic for a short amount of
> time trying to free-up memory and then finally throws OOME.
> Nothing meaningful seems to work after that: DBCPs run dry,
> etc. In these cases, I have had to restart my JVM completely
> in order for any users to get anything meaningful done.
>
> 2. Transient memory exhaustion: this happens when we have some careless
> code that loads 100,000 records from a single database query all
> into a big java.util.List or something like that. In these cases,
> a single thread gets an OOME, the List gets GC'd very quickly, and
> the server (and JVM) are fine. We generally do restart our JVMs when
> this happens, but we can wait until off-hours when fewer users are
> likely to be impacted in any way.
>
> > Alternatively, you could use a preexisting tool to monitor your
> Tomcat
> > instance like Nagios or Hyperic.
>
> These solutions really only monitor. Yes, you can configure them to
> "react" to certain situations by abusing the notification system, but
> they are really meant for monitoring and notification, not for
> automated tasks.
>
> >> I am using tomcat 6.0.14 on unix.
> >
> > This is really old, upgrade.
>
> +10
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEAREIAAYFAlEGmisACgkQ9CaO5/Lv0PAMeACfflakV2t8RT5kjF/wQf8joYl9
> swgAmgL1pwbvX5yLe2jUSGaOXXr5SDzf
> =MaHM
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
