And to expand on one other point, the shutdown mechanism is different
for the Windows Service (assuming you are using default jvm mode). You
don't have to worry about creating a whole new Java process just to send
the shutdown command to the shutdown port.
Mark
On 16/06/2021 21:47, Christopher Schultz wrote:
Jon,
On 6/16/21 14:31, jonmcalexan...@wellsfargo.com.INVALID wrote:
Ok, so this is a really good explanation. However, when setting up in
Windows as a Service, does the JAVA_OPTIONS in the Registry go in as
JAVA_OPTS or CATALINA_OPTS? Is there a way to have separate
CATALINA_OPTS for Tomcat Windows Services?
It's more complicated than you are making it seem.
If you use service.bat to create your Windows Service definition, then
the effective CATALINA_OPTS and JAVA_OPTS environment variable values
within the shell at the time you call bin\service.bat will have the
intended effect: they will combine and set the values which go into the
registry for that Service. When you launch the service, the (current)
values of CATALINA_OPTS and JAVA_OPTS, if they exist, are completely
ignored because the Service definition captured them at creation-time.
If you want to alter them, you can either set their values again, and
delete/re-create the service using bin\service.bat or you can use
tomcatXw.exe to edit the service values directly.
You have to remember that Windows, while supporting environment
variables nearly through-and-through, essentially encourages all
self-respecting Windows admins to ignore those environment variables.
Everything is done through the registry and so the Tomcat config scripts
attempt to bridge the gap between the gray beard UNIX admins who are
used to things like CATALINA_OPTS and JAVA_OPTS and whatnot and the
Windows admins who have an entirely different mental-model of system
services.
It's a neat little hack IMHO: let the CLI warriors set environment
variables and create a Service. The Service captures those values into
the more Windowsey paradigm, and off you go. And none of the Windows
admins have to bother themselves with environment variables.
-chris
-----Original Message----- From: Christopher Schultz
<ch...@christopherschultz.net> Sent: Wednesday, June 16, 2021 11:14
AM To: users@tomcat.apache.org Subject: Re: CATALINA_OPTS vs
JAVA_OPTS
Noelette,
On 6/16/21 11:29, Noelette Stout wrote:
Thanks! I was mostly trying to figure out if there was precedence
or if it was additive (i.e. 2GB to tomcat itself and another 2GB
to the apps). We're having some resource issues on one of our
servers, so I wanted to make sure I understood how the resources
were being
allocated.
No additivity at all: the last one on the command-line wins. There
is no heap separation between Tomcat and the applications: it's
one(ish) big, happy heap. :)
A note about CATALINA_OPTS versus JAVA_OPTS: when you use the
various scripts provided by Tomcat, CATALINA_OPTS is only used when
launching a Tomcat instance. JAVA_OPTS is used when launching *any*
Java process. There are many Java processes those scripts will
launch that aren't actually launching Tomcat. Examples include:
1. catalina.sh configtest 2. catalina.sh stop (also shutdown.sh) 3.
catalina.sh version 4. tool-wrapper.sh [anything]
In all of those cases, JAVA_OPTS will be passed to the JVM.
Do you really need a 2 gig heap to send a "shutdown" command to a
running server? Probably not.
-chris
On Wed, Jun 16, 2021 at 9:17 AM Rob Sargent
<rsarg...@xmission.com>
wrote:
On 6/16/21 9:06 AM, Noelette Stout wrote:
openjdk version "1.8.0_292"
On Wed, Jun 16, 2021 at 9:04 AM Rob Sargent
<rsarg...@xmission.com>
wrote:
Both as for the same minimum so you should get 2G at start up.
I'm not sure which has precedency but I would be on java opt.
I don't have a catalina env, but you can see how CATALINA_OPTS
is used in relationship with JAVA_OPTS
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
