Hi all, Just wanted to circle back. There was an early comment (maybe even in the first response to my question/problem) where someone mentioned that my set up (Running Tomcat as a Windows Service and putting the JMX parameters directly in the Tomcat7.0.54 GUI in the Java tab) SHOULD work and should startup and shutdown gracefully BUT that if it doesn't then try one of the of the later versions of Tomcat.
I did finally get a chance to try Tomcat 8.0.5X and it does seem to work with no other configuration changes. I can access JMX (JConsole) and start and shut down the Windows Service running Tomcat with no issues. Although, now my problem is that my third party application, that is running doesn't work, but that is not a problem for this mailing list. So I think we can say that in the end the upgrade to a higher version resolved the issue. Thank you to all that contributed input! - Louis -----Original Message----- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: Thursday, August 09, 2018 12:40 PM To: users@tomcat.apache.org Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54 - - - external message, proceed with caution - - - Maybe it is time here to quote Arthur Clarke's 3rd law : "Any sufficiently advanced technology is indistinguishable from magic" (See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws) The process by which Tomcat is started and/or stopped - particularly under Windows and as a Service - is not very clear in the on-line documentation. Neither is it it very easy to write a comprehensive and accurate documentation, because the thing has gotten to a point where, for mere mortals, it is really quite complicated. (Have a look at bin/catalina.bat to get an idea). So let me give you some overall pointers (some of them quite basic, I apologise), and maybe in there somewhere, you'll find wat you are missing to complete the picture and do what you want to do. 1) Tomcat is a compiled java application, in java bytecode. To run this bytecode, you need a JVM. The JVM is machine-executable code, so to run tomcat, you run a JVM and tell it to run the tomcat bytecode. 2) the java JVM for Windows is not very good at running as a Windows Service (it does not handle the appropriate Windows "signals" etc.). To solve this, when you want to run tomcat as a Windows Service (or rather - see above - run the JVM as a Windows Service), you actually run a specialised "wrapper program" which does work well as a Windows Service, and you ask this wrapper to start the JVM which runs tomcat. To make matters a bit more confusing (or maybe, for some, clearer), this generic "Windows Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the tomcat version, so for tomcat 9, the program is called tomcat9.exe). 3) the wrapper program, when it starts the JVM, has to know which command-line switches it should pass to it. For the Windows Service flavor of tomcat, these parameters are stored in a number of special keys in the Windows Registry, and that is where the wrapper picks them up, before starting the JVM. 4) To make it easier to set and edit these JVM command-line parameters, tomcat provides another Windows executable program - a specialised GUI Registry Editor - which is also renamed according to the tomcat version, as tomcatVw.exe (where V is the tomcat version, so for tomcat 9 it would be tomcat9w.exe). 5) as a separate bit of knowledge, I would suppose that everyone knows that on any given host, a given TCP listening port can only be opened by one process at a time. If a second process tries to open a port which is already opened by a first process, it will get an error of the kind "port already in use", and most probably the second process will then exit (non-gracefully). 6) in the tomcat conf/server.xml file, there is a tag : <Server port="8005" shutdown="SHUTDOWN"> This provides a clue as to how one actually *stops* tomcat : one opens a TCP connection to locahost port 8005 (on which tomcat listens), then sends the string "SHUTDOWN" on that connection. This causes tomcat to shutdown gracefully, at the end of which it does a "system.exit()" which shuts down the JVM that runs it. And this in turn causes the JVM wrapper program to tell Windows that the tomcat Service is shutting down, before itself exiting. And thus is all well and tidy in the Windows Service world. 7) a helpful feature of tomcat, is that it itself provides code to connect to localhost port 8005 and send that shutdown string, so that one does not have to write its own separate program to do that. The bit that is a bit confusing about this feature however, is that in order to use that code, one of course needs to start up another separate instance of tomcat, just to run that code and actually stop the "real" running tomcat. And of course running a separate instance of tomcat actually means running a separate instance of the JVM which runs tomcat. Now armed with all the above knowledge, and with the dialog window offered by the tomcat9w.exe program, it is relatively easy to figure out what happens (or at least what may happen in your case, in my modest non-java-expert opinion). Looking only at the last 3 tabs of that window (Java / Startup / Shutdown), one can figure out that : - the "java" tab contains the path of the JVM to be started, and the command-line parameters that will be passed to that JVM - the "Startup" tab contains the java class that the JVM should invoke at the start of tomcat, and the argument ("start") to pass into that initial call. - the "Shutdown" tab contains the java class that the JVM should invoke to stop an already-running tomcat, and the argument ("stop") to pass into that initial call. (Thus triggering the code in (7) above). And I believe that, in the particular case of Tomcat being run as a Windows Service, here may be the origin of the problem which you are encountering : the "Java" tab lists command-line options that are *common* to both the JVM which starts tomcat, and to the (separate) JVM which stops tomcat. There is only one set of JVM options, for both cases. Which means that if, in these JVM command-line options, you pass it one that tells the JVM to open some extra listening port (which you do to enable JMX), then this will happen both when a JVM is started because tomcat is being started, and when a JVM is started because tomcat is being stopped. And of course the second one will fail, because the first one has already opened that port. (Note that this will happen no matter which level of indirection you build into the Registry JVM parameters.) Why does that happen only with that JMX port, and not with the other listening ports that tomcat opens ? Well, that is a question of /when/ these different things happen : the JMX-port command-line parameter "happens" earlier, because it is something that the JVM does, before it evens starts running tomcat bytecode. While the other ports that Tomcat opens, happen in the code of tomcat itself, when it is being run. And that tomcat code is smart enough to know that when it is being run with the argument "stop", then it should not open these other ports mentioned in its configuration file. On the face of it, it seems a bit of an unsolvable issue, unless the tomcat Service wrapper code is changed, to allow for 2 separate sets of JVM parameters (one for start, with the JMX options; and one for stop, without these options). Or unless something is done in the Tomcat code itself, to allow JMX to be started (or not) from within Tomcat (assuming that's even possible). Of course, one could also wonder if you really need JMX when you run tomcat in production mode. If this is only for testing, you could run tomcat in a console, where you would not have the same issue (because you would not have the wrapper with its single-minded preset JVM options). (Or you could switch to Linux ;-)) On 09.08.2018 02:06, Daniel Savard wrote: > Le mer. 8 août 2018 à 12:08, Louis Zipes <louis.zi...@gmcr.com> a écrit : > >> >> Hi Calder, >> I can successfully start up as a Windows service and get JMX working BUT >> my problem is that Service doesn't stop cleanly (just repeating that >> problem in case it wasn't made clear). It says the PORT is already in use >> which led me to try to use Catalina_Opts as per the suggestions on the >> internet. >> >> Port already in use: 8008; nested exception is: >> java.net.BindException: Address already in use: JVM_Bind >> >> If you were able to get JMX working and you can start AND stop the Tomcat >> service cleanly, do you mind sharing me your 'scrubbed' Java tab contents >> as I can seem to get the right combination to get it to Start and Stop the >> service. >> >> Thanks, Louis >> >> >> > Louis, > > I believe you need to understand a bit more how things are working with > Java and the JVM. The -D options are pretty straight forward for anyone > knowing how you define properties to the JVM on the command line. I already > told you everything you need to know to setup properly your Tomcat. Since > you were the one talking about CATALINA_OPTS I assumed you did know where > and how to setup the variable for your installation. Otherwise, just go in > the setup utility for Tomcat on Windows and put the > -Dcom.sun.management.conf.file=${catalina.base}/conf/abc.def entry there > without the CATALINA_OPTS= stanza since this one's intent is to set an > environment variable for the process to pick while the former is passing > directly the property to the JVM from the Tomcat Windows Setup dialog. > There is many ways to do things. Bottom line, you need to tell the JVM > where is the configuration file for JMX and put your properties in there as > any other properties file. This is standard stuff. > > The effect is the JVM now knows your port is a JMX port and it will stop to > try to use it when it is already in use and free it cleanly. > > Regards, > > ----------------- > Daniel Savard > > >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------- CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may contain information that is confidential, proprietary or exempt from disclosure. If you are not the intended recipient, please contact the sender immediately. Unauthorized use or distribution is prohibited and may be unlawful. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
