Re: [Wrapper-user] Stopping a JVM, but leaving it around?

[Ole C. M. <ome...@sl...>]

At 17:54 24.10.2003, Leif Mortenson wrote:
>Ole,
>    Assuming that you have a way of telling when the JVM will really be 
> ready to exit,
>there are a few ways to do this.
>
>    The easiest would be to register a shutdown thread which is started 
> when the JVM
>starts to shutdown.  It would then continue to run until all of your 
>clients have
>completed.
>
>    The problem (feature) is that the Wrapper will by default kill the JVM 
> after about
>30 seconds.  To prevent this, you will need to tell the Wrapper that the 
>JVM needs
>more time.
>    One way of doing this is to extend the shutdown timeout in the 
> wrapper.conf file.
>This has the drawback of not knowing if the JVM needs more time or is 
>really hung
>on shutdown however.
>     A better method would be to have your shutdown loop call
>WrapperManager.signalStopping( Nms );  Each time this method is called, the
>Wrapper will be sure to allow that much time before the Wrapper gives up 
>and kills
>the JVM.
>    So if your shutdown thread calls WrapperManager.signalStopping( 30000 
> ) every
>10 seconds or so, the JVM would always quit within 30 seconds of your shutdown
>hook completing even if the JVM got stuck for some reason.

When I read the docs this looked promising, but I have another requirement 
that I did not mention. I need to the restart action to work as well and I 
assume by using signalStopping I would not get the fresh server started 
until the previous stop action has completed satisfactory?

>    Let me know if you have any questions.  Allowing the JVM to run for 
> relatively
>long periods of time after the JVM has been requested to exit is not the 
>norm.  The
>Wrapper supports it, but there are not many examples out there.

I understand, and I would not have implemented the server the way it is if 
I had a say, but it is a legacy app and hard to fix. The basic problem is 
that the server initializes it self with a lot of metadata from a database. 
It is not possible to reinitialize, one needs to restart the server. Since 
we use rmiregistry and stateful connections it is very easy to signal the 
running server to deregister and then register the new server. The previous 
server will then make sure to exit when all clients are logged off. Works 
smoothly.

I'm not giving up just yet, so how will the wrapper like it if I change the 
script to do the following on the stop action:

1. Execute my own command:
java SignalDeRegister server-name
2. Delete the pid file

Will the subsequent start continue ok since the pid file is gone or will it 
contact ports to find an existing wrapper process? When the server decides 
it is time to close how can I signal the wrapper that the close is fine and 
there is no need to restart? System.exit(0)?

Thanks for your help!

olec




>Cheers,
>Leif
>
>
>Ole Christian Meldahl wrote:
>
>>
>>My application is an RMI server that I want to put under Wrapper (great 
>>tool btw)
>>
>>I do have on problem, currently we stopping the server will
>>1. Block further connections
>>2. Unregister from rmiregistry
>>3. Stay alive until no more current clients
>>4. Shutdown JVM
>>
>>Is it possible to mimic this so that the
>>myapp stop
>>command will only execute the shutdown method and then leave the JVM 
>>running until it decides on it self to go down?
>>
>>olec
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: The SF.net Donation Program.
>Do you like what SourceForge.net is doing for the Open
>Source Community?  Make a contribution, and help us add new
>features and functionality. Click here: http://sourceforge.net/donate/
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user

----
Ole Christian Meldahl
Information Management Development - Stavanger
Schlumberger Information Solutions
mailto: ome...@sl...
+47 5194 6736