> -----Original Message----- > From: David kerber [mailto:dcker...@verizon.net] > Sent: Tuesday, March 04, 2014 11:32 AM > To: Tomcat Users List > Subject: Re: Shutdown port on Windows Service installation > > On 3/4/2014 12:04 PM, Jeffrey Janner wrote: > >> -----Original Message----- > >> From: David kerber [mailto:dcker...@verizon.net] > >> Sent: Tuesday, March 04, 2014 8:17 AM > >> To: Tomcat Users List > >> Subject: Shutdown port on Windows Service installation > >> > >> I am running several instances of TC 7 as services on a Windows > >> Server > >> 2008 R2. Each instance has its own set of ports, and I have both > the > >> data port and shutdown ports configured in server.xml. They are > >> currently running only HTTP. > >> > >> My questions: > >> > >> 1. Does the shutdown port serve any purpose on a windows service > >> installation? I thought I had read that it did not, but some > >> searching didn't turn up a definitive answer. > >> > > The shutdown port is not needed for a Windows service, but it is > usable if configured. > > In other words, assuming the default configuration, if someone were > to send "SHUTDOWN" to the localhost port 8005, then Tomcat would > shutdown. > > Ok, I think I'll disable that. We always use the service controls. > > > > > I couldn't tell from the documentation > (http://tomcat.apache.org/tomcat-7.0-doc/config/server.html), but I > seem to recall that the "port" attribute is required on the <Server> > tag. For all my Windows installations, I just set it to -1 and let the > Commons Daemon implementation (tomcat.exe) take care of the shutdown > task. > > FYI: Tomcat implements the Java Daemon API, which is the mechanism > that the Apache Commons Daemon > (http://commons.apache.org/proper/commons-daemon/) executables use to > communicate with the Tomcat. The ACD is a C program that loads the JVM > and tells it to run the Tomcat bootstrap. Then it just listens for > system signals. There is a Windows version (procrun) and a Unix/Linux > version (jsvc). This is a separate utility that you can use if you > have standalone Java programs you need to run as a service. > > BTW: The JVM exits when Tomcat issues a System.exit() call. > > So -1 disables the shutdown port, right? > Correct! > > > > >> 2. I may need to start using HTTPS for my data transfer for at > least > >> one of the instances. If that instance is going to allow only HTTPS > >> (and not HTTP), can I just make the current HTTP port into HTTPS? > Or > >> do I need to configure an additional port? If I need an additional > >> port, and the shutdown port isn't needed, I could just turn the > >> shutdown port into the HTTPS port, right? > >> > > You don't mention your setup, but I would use the standard HTTPS port > of 443 and actually provide both the HTTP and HTTPS connectors, then > configure the application to force HTTPS where necessary via the > web.xml directives. > > But then again, it depends on your implementation. > > The ports are different for each TC instance, but I can give each > instance an extra port if needed. > > > > > >> I understand that there are significant configuration changes needed > >> for HTTPS, and will be back if I run into issues with it, but for > now > >> I'm only asking about the TCP ports. > >> > >> Thanks! > >> Dave > > > > Be careful of whether you are also running with the native/APR > library. The SSL configuration requirements are different if doing so. > It is all well documented in the Tomcat documentation. > > > Thanks for the comments, Jeff. I'll definitely be running the native > lib for performance reasons. A couple of the instances get around 4M > transactions per day, and we total well over 10M per day across all the > instances. So I want to keep the load as small as I reasonably can. > When it comes time to issue the signed certificate from whatever CA you decide to use, be careful which version you pick. Some will offer a choice of "Tomcat", but that will get you a certificate useful for the native-Java SSL implementation. You will want to be sure to pick the "Apache" offering. Jeff
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
