Re: [Wrapper-user] Newbie (?) Questions

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

Georg,
    Ok, I got both of this issues implemented / fixed.  They will be in 
the next release.
See below for comments.

Georg Schmid wrote:

> Leif,
>
> thanks for the detailed explanation. I have understood all the points 
> you made.
>
> I  cannot agree with you on the first point. The practical effect is, 
> that, if the process runs into an error condition, which does not go 
> away through restarting, the crashing-and-restarting process will loop 
> forever (which has to be avoided under all circumstances. It may take 
> several hours, until the service people react and fix the situation. 
> During this time the endless loop may do a lot of harm by opening more 
> and more files and database connections without closing them, which 
> may exhaust the available file handles as well as the maximum number 
> of database connections, all in all creating a lot more damage than 
> simply staying down after 5 retries). Moreover, according to the 
> documentation, the retry count will be reset, if the process has been 
> running successfully for more than a specified time. 

    This made good sense, so the Wrapper no longer treats restarts 
triggered by
calling WrapperManager.restart() or those triggered by a filter, 
specially.  Any
restart will cause the failed invocation count to be incremented if the 
JVM was
running for less than the configured successful invocation time.

> For the second issue there has to be made a difference between the 
> reaction of the process controlled by the wrapper and the wrapper 
> itself. Even if the wrapper restarts a process that has received a 
> TERM, the wrapper itself can still react to this signal by shutting 
> down.  But this is not the point.  The wrapper should NOT go down when 
> receiving a TERM, it should stay. Otherwise it would be vulnerable 
> itself to a forgotten "nohup" or, taking my situation, TERM signals 
> with unknown sources.
> Instead it should be possible to shutdown the wrapper by, for 
> instance, creating a "well-known" file. Many of the processes in our 
> manufacturing environment catch all signals they can, because they 
> must not be interrupted in their activities during certain periods of 
> time and are shut down in this way.
>
>> Processes should always respond to a kill TERM by exiting gracefully.
>
>
> Not always. For instance, if the foreground process of a Bourne shell 
> gets a Ctrl-C, the shell sends a TERM to all processes it has started 
> in the background. The background processes should, of course, ignore 
> this TERM in this situation. (I only know this, because there is a 
> related JDK1.4 bug). 

I added a new wrapper.ignore_signals property which, if set, will cause the
to ignore TERM and INT signals on UNIX, and CTRL-C and Window CLOSE
events on Windows.  It is documented, but as is, the scripts which ship with
the Wrapper will not be able to stop the Wrapper if this property is set.

How are you planning of having your application shut itself down?  I may 
need
to do some more work here to maybe create a shell script that kills the
Wrapper by deleting its pid file rather than sending a TERM signal.  Doing
so would mean that the Wrapper would have to poll for the existence of 
the file
to decide when to exit.  Thoughts?

If you find these features and support useful, please consider 
supporting the
project.
http://wrapper.tanukisoftware.org/doc/english/donate.html

Cheers,
Leif