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

[Georg S. <geo...@ti...>]

Leif,

that is really great, thanks a lot!

My intention is to use the  JMX web interface to shutdown JBoss cleanly. 
Of course not all applications have an additional interface for shutting 
down, unlike JBoss or Tomcat. Instead of using a PID or similar file the 
wrapper could use the Tomcat approach and listen for a shutdown command 
on a well-known port, or implement a JMX interface.

[When we actually start using the wrapper in our production environment 
I am going to talk about the money issue with my boss.]

Regards
Georg

Leif Mortenson wrote:

> 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
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user


-- 
--
Georg Schmid
Special Applications Section Manager   mailto:geo...@ti...
Freising Wafer Fab (FFAB) Make IT      phone: +49 8161 804595
Texas Instruments Deutschland GmbH     fax: +49 8161 803350