its an asynchronous call, all shutdown.sh does, is connect to the
shutdown port and issue the shutdown command,
when shutdown.sh returns, there is no guarantee that the java process
has been shutdown, that depends on the webapplications installed
Filip
brycenesbitt wrote:
Odd. I call shutdow
Odd. I call shutdown and start in the same thread (so shutdown completes
before the startup happens). AFIK, shutdown actually does shut down the
java process. If shutdown is not meant to shut down the java process, what
does it do?
Filip Hanik - Dev Lists wrote:
>
> the problem you are havin
the problem you are having is because you didn't shutdown the java process.
invoking shutdown.sh when your tomcat instance has suffered a memoryleak
doesn't guarantee that it will stop, or how long it takes to stop it.
you must ensure the process is killed properly
Filip
Bryce Nesbitt wrote:
We've recently had a related problem. When tomcat can't bind to port 6135,
it binds to the next port up, 6136. Unfortunately that's a totally
different application. Is there a way to:
1) Have Tomcat not bump the port number up.
2) Have Tomcat retry a particular port until it's available.
Unfo
Bryce Nesbitt wrote:
Do we have to wait at least 20 seconds to be sure the port is clear?
The easiest thing is to do 'killall -9 java' ;-)
I run Tomcat under its own account. And restart script looks like this:
#!/bin/sh
~/bin/shutdown.sh
sleep 10
killall -9 java
~/bin/startup.sh
There's n
