#107 signalStopping(...) causes immediate death from Wrapper

[Anonymous]

I have wrapped my code around with the Wrapper, and in
my main class, I have the following stop code:

public int stop\(int exitCode\) \{
    Thread thrWait = new Thread\(\) \{
        public void run\(\) \{
            server.closeAllClients\(\);
        \}
    \};
    thrWait.start\(\);
    while \(thrWait.isAlive\(\) || server.isAlive\(\)\) \{
        try \{
            WrapperManager.signalStopping\(800\);
            Thread.sleep\(500\);
        \} catch \(InterruptedException e\)\{\}
    \}return exitCode;
\}

I have installed the app as a Service in Windows XP PRO
SP2.

The problem is, whenever I shutdown the service, I get
this...

INFO | jvm 1 | 2006/03/03 10:51:49 | Query Runner
Ended
ERROR | wrapper | 2006/03/03 10:51:49 | Shutdown
failed: Timed out waiting for signal from JVM.
INFO | jvm 1 | 2006/03/03 10:51:49 |
ChartBuilderThread Ended
ERROR | wrapper | 2006/03/03 10:51:49 | JVM did not
exit on request, terminated
STATUS | wrapper | 2006/03/03 10:51:50 | <-- Wrapper
Stopped

(Query Runner is our internal code).

When I set the value of wrapper.shutdown.timeout to 0,
and then comment out the signalStopping method, it
shuts down fine:

INFO | jvm 1 | 2006/03/03 11:00:20 | Query Runner
Ended
INFO | jvm 1 | 2006/03/03 11:00:21 |
ChartBuilderThread Ended
STATUS | wrapper | 2006/03/03 11:00:22 | <-- Wrapper
Stopped

(ChartBuilderThread is also our internal code).

Also, when running the signalStopping method from the
console, the same error appears:
wrapper | CTRL-C trapped. Shutting down.
jvm 1 | Query Runner Ended
jvm 1 | ChartBuilderThread Ended
wrapper | Shutdown failed: Timed out waiting for
signal from JVM.
wrapper | JVM did not exit on request, terminated
wrapper | <-- Wrapper Stopped

Many thanks,

David Hayes

[Nobody/Anonymous]

Logged In: NO

Neglected to mention that it is version 3.1.2 of the Wrapper.

Many thanks,

David Hayes

[Nobody/Anonymous]

Logged In: NO

With Wrapper.Debug=true

DEBUG | wrapper | 2006/03/03 11:26:48 | SERVICE_CONTROL_STOP
DEBUG | wrapper | 2006/03/03 11:26:48 |
wrapperStopProcess(0) called.
DEBUG | wrapper | 2006/03/03 11:26:48 | Sending stop
signal to JVM
DEBUG | wrapperp | 2006/03/03 11:26:48 | send a packet STOP
: NULL
INFO | jvm 1 | 2006/03/03 11:26:48 | Received a packet
STOP :
INFO | jvm 1 | 2006/03/03 11:26:48 | Thread,
Wrapper-Connection, handling the shutdown process.
INFO | jvm 1 | 2006/03/03 11:26:48 | calling
listener.stop()
INFO | jvm 1 | 2006/03/03 11:26:48 | Send a packet
STOP_PENDING : 800
INFO | jvm 1 | 2006/03/03 11:26:48 | Query Runner Ended
DEBUG | wrapperp | 2006/03/03 11:26:48 | read a packet
STOP_PENDING : 800
DEBUG | wrapper | 2006/03/03 11:26:48 | JVM signalled a
stop pending with waitHint of 800 millis.
INFO | jvm 1 | 2006/03/03 11:26:48 | ChartBuilderThread
Ended
ERROR | wrapper | 2006/03/03 11:26:48 | Shutdown failed:
Timed out waiting for signal from JVM.
ERROR | wrapper | 2006/03/03 11:26:49 | JVM did not exit
on request, terminated
STATUS | wrapper | 2006/03/03 11:26:49 | <-- Wrapper Stopped

Many thanks,

David Hayes

[Nobody/Anonymous]

Logged In: NO

I think I know why this is happening now...

I have taken a quick shufty around the src code.

The first thing that you do with the signalStarting/Stopping
millis, is do an integer division by 1000. Effectively, what
this does is make any millis value <1000 fail over immediately.

I think that the Javadocs should be modified to say that
whilst the value for signalStarting/signalStopping is
allowed to be provided in Millis, the actual value will be
integer divided into seconds (rounding down). So if you have
a value of <1000 you effectively say don't wait at all (the
seconds difference is 0), and you should use a multiple of
1000 to get guaranteed results.

Just one to be aware of.

Many thanks,

David Hayes

[Davy Boy]

Logged In: YES
user_id=1467052

As I am aware of the problem, and the workaround (and have
documented it with this bug, so others can see it), I am
happy to close this bug if you would like, or at least drop
the priority considerably.

Many thanks,

David Hayes

[Leif Mortenson]

Logged In: YES
user_id=228081

David,
Thanks for looking into the cause of this. I'll get the
docs updated and see if I make it handle that case better.
It is used to extend the timeout, so it would probably make
the most sense to round up to the next second. I've already
cut off 3.2.0. But I'll get this into the next release.

Cheers,
Leif

[Leif Mortenson]

Logged In: YES
user_id=228081
Originator: NO

The Wrapper was modified in 3.2.1 to round all timeout values up to the next second. Furthermore changes were made for 3.3.0 so that it is no longer possible to shorten a timeout using the signalStarting or signalStopping methods.

Cheers,
Leif