On Fri, Oct 16, 2009 at 04:39:43PM -0700, Jordan Brown wrote: > Jens Elkner wrote: > >IMHO JMX is the right way to manage Java apps, not some artificial stuff > >outside of its "domain". Havn't used tomcat since GF 2 is on stage, but > >IIRC it supports JMX as well ... > > Administrators should not have to know nor care what language was used to > implement a service. There should be one mechanism for all service > management, whether the service is implemented in C, Java, shell scripts, > for Fortran.
Hmmm - depends of the POV. At least performance concerned people will probably not agree. Its like saying, if you have a driving license, you shouldn't care about the vehicle you are driving or the fuel it needs ;-) Anyway, trying to manage services via PIDs and signals seems to be odd, especially in the java env because there are even no appropriate methods to handle them (and that's for reason). And as Nico already pointed out, every service (not matter which kind of implementation) should provide a facility to communicate with it and manage it. Doing this by relying on PIDs (which are at least after a reboot/restart always different) and sending OS signals to pids is pretty old style fashion and unreliable, not just because the possebgility to send the sigs to the wrong process but also because one gets no feedback. BTW: I've seen so many bogus startup scripts/services which say: Oh I found a pid file - doing nothing since the service must already been running. They don't even check the process table, whether a process with the given pid exists (and after a kill -9 or crash it usually doesn't)! Trying to fix this with an artificial pid FS system is IMHO senseless and leads totally into the wrong direction (and BTW, nobody would probably make use of it, since other OS don't have such a thing either). So IMHO one should not waste its time with thinking about a new PID FS but rather why /var/run is needed at all ... Coming back to JMX: It is just one way to provide a management interface for java apps - it takes only a couple of lines to provide "reconfigure", "[gracefully] shutdown" operation and thus IMHO ideal for management and one has the benefit, that one is able to manage them even with generic GUIs (e.g. jconsole, jManage, MC4J) (OT: would be nice, if there would exist a lib for C apps, which provides similar functionality ;-)). Back to Tomcat: It uses its own bootstrapper to communicate with the service and it actually doesn't need the pid as well. However, there is a 'stop -force' option, which uses 'kill -9 $CATALINA_PID' if the normal "bootstrap stop" didn't work, but only, if CATALINA_PID is set - which is per default not the case. And IIRC nobody actually uses catalina.sh directly to manage tomcat but rather use its startup.sh and shutdown.sh scripts, which don't provide the -force option. So the whole PID thing there is more or less a bad kludge/relict and if really wanted, killing all PIDs in the appropriate contract would accomplish the same or probably even in a more reliable way ... So don't bloat the OS with stuff, which nobody needs! My 10?. Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768
