You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2002/07/01 19:05:04 UTC

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Jk2 shutdown

Posted by co...@covalent.net.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Jk2 shutdown

Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net] 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Jk2 shutdown

Posted by co...@covalent.net.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Jk2 shutdown

Posted by Mladen Turk <mt...@mappingsoft.com>.

> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net] 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Jk2 shutdown

Posted by co...@covalent.net.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>