Jk2 shutdown
Hi, There are few things left with the gracefull TC shutdown. 1. The Apache version works ok. 2. The IIS shutdowns the TC but the dll is still left loaded. Think that the TomcatStarter is left hanging, cause stdout/stderr redirection files stays opened. I would like to make the TomcatStarter to be aware of the thing that he is doing (starting or stopping). Could be done through args but I would like to hear other ideas. Second thing is the 'ARG' parameter that IMO should be split in two params, (startup and shutdown) like [worker.jni:jniCmd1] ... startup=start shutdown=stop MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2 shutdown
On Mon, 1 Jul 2002, Mladen Turk wrote: I would like to make the TomcatStarter to be aware of the thing that he is doing (starting or stopping). Could be done through args but I would like to hear other ideas. Second thing is the 'ARG' parameter that IMO should be split in two params, (startup and shutdown) like [worker.jni:jniCmd1] ... startup=start shutdown=stop What I tried in jniCmd and jni worker is to make it as simple as possible - just call main(String[]) with all the standard arguments. It is the protocol and the exposed API who should provide any aditional callback - the jni worker should do one thing, load the VM and start a standard program. We already have a mechanism/API for shutdown - and I don't see any good reason to add another one for the JNI call. The fewer 'special' APIs we have for JNI, the better it is for maintainance. What I would do is just use the existing ajp13 shutdown. If there's anything the TomcatStarter must do on shutdown, we can add another hook (== coyote ActionCode ) for shutdown, but use the normal callback mechansim from JNI ( with the ajp13 shutdown message ). If this is too complicated - I'm +0 on a temporary solution, but long term I think we should keep the API consistent and as simple as possible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 1. srpanj 2002 19:40 To: Tomcat Developers List Subject: Re: Jk2 shutdown On Mon, 1 Jul 2002, Mladen Turk wrote: We already have a mechanism/API for shutdown - and I don't see any good reason to add another one for the JNI call. The fewer 'special' APIs we have for JNI, the better it is for maintainance. Yes, but It doesn't work, at least I wasn't been able to invoke it. And it isn't API, it just calls the TomcatStarter with the stop param, and the change of ARG init param, enables that 'stop' to be customizable (if its gonna be changed someday). What I would do is just use the existing ajp13 shutdown. If there's anything the TomcatStarter must do on shutdown, we can add another hook (== coyote ActionCode ) for shutdown, but use the normal callback mechansim from JNI ( with the ajp13 shutdown message ). We still need to destroy the jvm on shutdown, and since we are using the TomcatStarter for starting I'm pretty much in favor for using it for shutdown too, cause that's our application entry point when used inprocess. If something else provoke the shutdown then we'll need another callback or jkSetAttribute, to signal the jni worker to destroy the jvm. MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Mladen Turk wrote: On Mon, 1 Jul 2002, Mladen Turk wrote: We already have a mechanism/API for shutdown - and I don't see any good reason to add another one for the JNI call. The fewer 'special' APIs we have for JNI, the better it is for maintainance. Yes, but It doesn't work, at least I wasn't been able to invoke it. And it isn't API, it just calls the TomcatStarter with the stop param, and the change of ARG init param, enables that 'stop' to be customizable (if its gonna be changed someday). I was thinking that 'stop' should be done by sending the ajp13 stop message, instead of calling main(). worker.jni should just execute a program by calling static main(String args[]). What about having a separate worker.jni: that will execute the stop command ? In theory we can have as many worker.jni we want, each executing different programs - in this case we'll just add a flag to the worker.jni indicating when do we want the program executed ( on start, on stop - maybe on other stages too ). This would still keep the worker.jni: as a simple run-java-program-and-nothing-else, and we could open some interesting tricks. What I would do is just use the existing ajp13 shutdown. If there's anything the TomcatStarter must do on shutdown, we can add another hook (== coyote ActionCode ) for shutdown, but use the normal callback mechansim from JNI ( with the ajp13 shutdown message ). We still need to destroy the jvm on shutdown, and since we are using the TomcatStarter for starting I'm pretty much in favor for using it for shutdown too, cause that's our application entry point when used inprocess. Not sure about that - I would like to keep TomcatStarter as simple as possible. I don't agree that the same class that starts a program should also stop it - we don't do it in standalone case ( where the stopper sends a message to either ajp12/13 in 3.3, or the 8005 port in catalina - but that's different code than the starter code ). As allways, if adding a stop solves your problem - I'm +0, but I don't think this is the best solution, and long term I would like very much to have the stop done via the same code regardless of execution mode. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 1. srpanj 2002 21:31 To: Tomcat Developers List Subject: RE: Jk2 shutdown What about having a separate worker.jni: that will execute the stop command ? In theory we can have as many worker.jni we want, each executing different programs - in this case we'll just add a flag to the worker.jni indicating when do we want the program executed ( on start, on stop - maybe on other stages too ). This would still keep the worker.jni: as a simple run-java-program-and-nothing-else, and we could open some interesting tricks. Cool idea! I was thinking to use it just for something like that. Not sure about that - I would like to keep TomcatStarter as simple as possible. I don't agree that the same class that starts a program should also stop it - we don't do it in standalone case ( where the stopper sends a message to either ajp12/13 in 3.3, or the 8005 port in catalina - but that's different code than the starter code ). Well, I was thinking to customize and use the TomcatStarter mainClasses[] so we can start not only Bootstrap but other classes too, making extra call param to the main and put those classes to be either fixed or customizable. That way the existing code would be kept as much usable, with the minor adjustments. So, using the TomcatStarter calling some classes main() with the start/stop is a nice and clean interface to as many loaded classes as they are. Instead of customizing the TomcatStarter class in the worker.jni: I'd like to make the actual called class to be customized, but the problem is with those multiple mainClasses[] (perhaps semicolon separated?). As allways, if adding a stop solves your problem - I'm +0, but I don't think this is the best solution, and long term I would like very much to have the stop done via the same code regardless of execution mode. Ok, I agree. It works for now, but I'll look a way to make the clean shutdown using ajp (and TomcatStarter :). MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Mladen Turk wrote: Well, I was thinking to customize and use the TomcatStarter mainClasses[] so we can start not only Bootstrap but other classes too, The mainClasses[] is just a hack - so I can start any of 3.3, 4.0 and 4.1 by just changing TOMCAT_HOME variable. It should work fine by just editing workers.properties and using the 'real' Main.java/Startup.java/whatever has a main()/. So, using the TomcatStarter calling some classes main() with the start/stop is a nice and clean interface to as many loaded classes as they are. I think you should be able to call any java class with main() with any arguments - TomcatStarter is just one case, which detects the version and re-dispatch. Instead of customizing the TomcatStarter class in the worker.jni: I'd like to make the actual called class to be customized, but the problem is with those multiple mainClasses[] (perhaps semicolon separated?). I think it is already customizable - you can set the name of the class to be executed by worker.jni, and any of the arguments. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
It should work fine by just editing workers.properties and using the 'real' Main.java/Startup.java/whatever has a main()/. How we can deal with stdout and stderr redirection?, just now jk2 is passing the file names as params to TomcatStarter, and this will not work if using standard main methods, i will change it to be defined properties at vm level, and using them in TomcatStarter for now.. Is there are a standard way to redirect stderr and stdout in 4.1.X at container level ? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Ignacio J. Ortega wrote: It should work fine by just editing workers.properties and using the 'real' Main.java/Startup.java/whatever has a main()/. How we can deal with stdout and stderr redirection?, just now jk2 is passing the file names as params to TomcatStarter, and this will not work if using standard main methods, i will change it to be defined properties at vm level, and using them in TomcatStarter for now.. Can we move the stdout/stderr redirection to some static util method, in AprImpl ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 1 de julio de 2002 23:16 Can we move the stdout/stderr redirection to some static util method, in AprImpl ? Any reason to so? i think this would be and overkill, i think pasing the file names as properties is the cleanest way.., in fact i like much more this way, than the way i did it.. org.apache.jk.stdout, org.apache.jk.stderr are ok, as system properties names ? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
On Mon, 1 Jul 2002, Ignacio J. Ortega wrote: De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: 1 de julio de 2002 23:16 Can we move the stdout/stderr redirection to some static util method, in AprImpl ? Any reason to so? i think this would be and overkill, i think pasing the file names as properties is the cleanest way.., in fact i like much more this way, than the way i did it.. worker.jni would call AprImpl and have System.out, System.err redirected. This will allow us to execute any existing java program, without the need to change it to interpret some system properties or do anything special. Well, the current code is not doing that - we do call static void main( String args[], String stdout, String stderr ). I personally think we should call the 'real' main(String args[]), there is little value in creating another startup mechanism. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 shutdown
worker.jni would call AprImpl and have System.out, System.err redirected. Done, seems much better, thanks. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
