Re: [Wrapper-user] Performing actions on (re)start, shutdown of JVM

[Leif M. <le...@ta...>]

Martin,
    That is on my todo list, but it is not going to make it into the 
3.2.0 release.  That has
already been delayed long enough.

    If the JVM crashes for any reason, it will by default be restarted.  
For that reason,
you should always get a final clean shutdown when you ask the wrapper to 
stop.
It is not perfect, but doing what you are asking for in a shutdown 
thread should be
fairly reliable.  (Not 100% though).  Most shutdown methods will result 
in these
shutdown hooks being called.  The exceptions are calling
WrapperManager.stopImmediate(), Runtime.halt(), or by kill -9ing the JVM 
process.
All but the stopImmediate case will result in the JVM beign restarted 
however.

    I am planning to make it possible to run arbitrary processes at 
various points in the
Wrapper life cycle.  Its not possible in 3.1.2 or 3.2.0 however.

Cheers,
Leif

Martin Gazak wrote:
> Hallo,
> when using Wrapper 3.1.2 with my Java application, my Java application 
> requires to perform some specific actions during start/RESTART of JVM 
> and shutdown of JVM.
> These actions include, but are not limited to:
> - deleting device lock files on certain platforms (e.g. serial line 
> locks on Linux)
> - shutdown of heartbeat service
>
> The shutdown actions must be performed no matter what type of shutdown 
> occured ( WrapperManager.restart(), stop, stopImmediate() calls;
> System.exit() call; crash of JVM (both in Java and Native code), 
> killing JVM process from command line).
>
> Is it possible to configure wrapper to perform these actions (e.g. in 
> the form of calling some scripts) ?
>
> The naive try = launching my script "runjava" (which performs the 
> start actions, runs JVM and then performs shutdown actions) from 
> wrapper.java.command does not work properly - wrapper was watching the 
> /bin/sh instead of java process, sometimes java processes kept 
> accumulating when I was playing (since wrapper took care for shell 
> processes, not for the increasing number of JVM).
>
> Thanks in advance.
>
>
> Martin
>