Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

Leif,

Where is this symbolic link stored?  Because this was a major upgrade
I renamed the existing folder (prefixed it with _) and uploaded the
new program to the prior folder name, but now I see the log output is
going to the old renamed folder.  This would work just fine on
Windows.  Not sure what I have to do to fix any links that may point
to the renamed old folder.

Thanks,
-Dave

On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
<lei...@ta...> wrote:
> David,
> Just stopping should be fine.   "Installing" on a UNIX system is
> simply creating symbolic links to the script in most cases.
>
> Please let me know how it works for you.
>
> Cheers,
> Leif
>
> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>> Leif,
>>
>> I'm about ready to deploy this change.  I understand it needs to be stopped
>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>> Or just stop and restart?
>>
>> Thanks,
>> -Dave
>>
>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>> <lei...@ta...> wrote:
>>>
>>> David,
>>> The controlEvent method gives you a chance to either handle or ignore
>>> the signal within the JVM process.  This is a very old API and the
>>> problem with it is that the Wrapper process may also receive a TERM
>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>> shutdown process regardless of what this method does.   For this
>>> reason, this method is more useful as a reporting method.
>>>
>>> To prevent your application from responding to TERM signals, you will
>>> want to use the wrapper.ignore_signals property
>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>
>>> On UNIX, the recommended way of doing this is to set the
>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>> made as it changes the way the script controls the Wrapper.
>>> Please see the above page for more details.
>>>
>>> Let me know how this works for you.
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>> > I have the wrapper installed on Linux as a service and need as close
>>> > to 100% up time as is possible.  The wrapper recently received a
>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>> > controlEvent() is like this...as copied from some JSW sample code...
>>> >
>>> > public void controlEvent(int event) {
>>> >
>>> >         try {
>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>> >                 // The Wrapper will take care of this event
>>> >             } else {
>>> >                 // We are not being controlled by the Wrapper, so
>>> > handle the event ourselves.
>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>> >                     log.warn("We are handling the received event
>>> > ourselves and we are stopping the service");
>>> >                     WrapperManager.stop(0);
>>> >                 }
>>> >             }
>>> >         }
>>> >     }
>>> >
>>> > Now I see that recent javadocs say to use...(unless one knows what
>>> > they are doing)
>>> >
>>> > public void controlEvent( int event )
>>> >  {
>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>> > WrapperManager.isLaunchedAsService() )
>>> >        {
>>> >            // Ignore
>>> >        }  else   {
>>> >           WrapperManager.stop( 0 );
>>> >        }
>>> >  }
>>> >
>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>> > provides 100% up time, rather it just shuts things down cleanly.
>>> >
>>> > What is the right way to handle this?  I.e. should I ignore the
>>> > signal?  should I restart after shutdown?  How?
>>> >
>>> > Thanks,
>>> > -Dave
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>