wrapper-user — User issues for Wrapper. (Support questions, etc.)

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

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

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
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

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

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

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

[Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

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

Re: [Wrapper-user] Launched daemon on Mac OSX appears in Dock and in Menu Bar

[brian m. <br...@gi...>]

Thanks, Leif,

I am not wittingly enabling any GUI, but I suspect you are right; I also
tested with a console app and things went as expected.

Thanks for the help.

Brian

On Mon, May 9, 2011 at 12:21 AM, Leif Mortenson <
lei...@ta...> wrote:

> Brian,
> Does your application have a GUI that is being displayed?   I just
> checked and confirmed that console based applications do not cause an
> icon to be displayed.
>
> For Swing applications, you can handle the close even when the user
> clicks to close the window using the windowClosing method of a
> WindowListener.   But I tried it and the menu bar's Quit choice does
> not use that.  Nor does it appear to be killing it with a TERM signal.
>
> Digging around a bit more.  I think I found what you want:
>
> http://stackoverflow.com/questions/2061194/swing-on-osx-how-to-trap-command-q
>
> http://developer.apple.com/library/mac/#samplecode/OSXAdapter/Introduction/Intro.html
>
> I have not had a chance to try it out yet, but it looks like this will
> actually make it possible to cancel the CMD-Q request.   We will look
> into to whether or not it makes sense to add this into the core
> Wrapper for a future release.
>
> Please let me know how this works for you.
>
> Cheers,
> Leif
>
> On Thu, May 5, 2011 at 1:36 AM, brian mcgann <br...@gi...>
> wrote:
> > I am using wrapper-32-3.5.7.jar and am successfully launching my daemon
> on
> > Mac OS X Snow Leopard, however when running, an icon for the daemon
> appears
> > on the dock and also appears on the menu bar, complete with a 'Quit' menu
> > item.  How can I avoid this?
> >
> > Thanks,
> >
> > Brian McGann
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Java Service Wrapper 3.5.9

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

Hi all,
I would like to announce the release of 3.5.9 of the Java Service
Wrapper.  This version is primarily a bug fix release:

*) We had made a silly mistake for the 3.5.8 release which has
prompted us to do another release so quickly.  Some testing code was
left in the source which was preventing the Wrapper from reporting any
hostId from certain IBM based network cards.  This was only a problem
on the Standard and Professional editions and would only affect new
users as existing licenses worked correctly.

*) We also discovered problem which has been in the Wrapper since
version 3.4.0 which can cause the Wrapper to trigger a JVM timeout if
the JVM is sending a constant stream of console output for longer than
the ping timeout.  We also made a couple related tuning changes.  The
result is that 3.5.9 is much more stable with respect detecting when a
JVM is frozen and needs to be restarted when the system or JVM are
under extreme high loads.

Please see the release notes for a full list of changes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html#3.5.9

The full release is available on the Wrapper site:
http://wrapper.tanukisoftware.com/doc/english/download.jsp

In addition to our internal testing, when release new versions, they
are released as "Unstable" for a period of approximately 2 weeks.   If
after that time we have not received any reports of critical problems
the version will be upgraded to "Stable" on the site.  This makes it
possible for you to decide whether you would like to try out the
latest and greatest version or stick with a safer known version for
deployment with your applications.

As always, please let us know how we can continue to improve the Java
Service Wrapper to meet your needs.

Sincerely,
Leif Mortenson
Tanuki Software, Ltd.
http://www.tanukisoftware.com

Re: [Wrapper-user] Wrapper "StartServiceControlDispatcher failed!"

[Peter B. <pbe...@am...>]

Christian,

it's the account being used for all the services.
As you can see, some start and some don't.

Thanks
Peter




From:   Christian Mueller <chr...@ta...>
To:     wra...@li...
Date:   10-05-11 10:37
Subject:        Re: [Wrapper-user] Wrapper "StartServiceControlDispatcher 
failed!"



Peter,

could you please verify the specified account
"MUCMSPDOM\svcGlobalMonitor" has the rights to logon as a service?
I think that it might be very likely that this is the problem...

You can find this information in the local security policy:
http://technet.microsoft.com/en-us/library/cc739424%28v=ws.10%29.aspx

In 3.5.8 I have added a check adding that privilege for an account if
it's missing.
http://sourceforge.net/tracker/index.php?func=detail&aid=3286491&group_id=39428&atid=425190


Cheers,
Christian

On Mon, May 9, 2011 at 7:46 PM, Peter Beecken <pbe...@am...> 
wrote:
>
> Leif,
>
> Thanks for the quick response.
>
> I move one group to server2 (MUCTXP1B) and this time all resource group
> members came online except for one:
>
> The cluster resource is offline(failed)  now and I tried:
>
> G:\>G:\SCheck_DZA_PRD\wrapper.exe -t 
G:\SCheck_DZA_PRD\\conf\wrapper.conf
> wrapper  | Starting the SCHECK_DZA_PRD service...
> wrapper  | Unable to start the SCHECK_DZA_PRD service - The service did 
not
> respond to the start or control request in a
>  timely fashion. (0x41d)
>
> G:\>G:\SCheck_DZA_PRD\wrapper.exe -r 
G:\SCheck_DZA_PRD\\conf\wrapper.conf
> wrapper  | SCHECK_DZA_PRD service removed.
>
> G:\>G:\SCheck_DZA_PRD\wrapper.exe -i 
G:\SCheck_DZA_PRD\\conf\wrapper.conf
> wrapper  | Service command: G:\SCheck_DZA_PRD\wrapper.exe -s
> G:\SCheck_DZA_PRD\conf\wrapper.conf
> wrapper  | Prompting for account password...
> Please input the password for account 'MUCMSPDOM\svcGlobalMonitor': 
********
> wrapper  | SCHECK_DZA_PRD service installed.
>
> G:\>G:\SCheck_DZA_PRD\wrapper.exe -t 
G:\SCheck_DZA_PRD\\conf\wrapper.conf
> wrapper  | Starting the SCHECK_DZA_PRD service...
> wrapper  | Unable to start the SCHECK_DZA_PRD service - The service did 
not
> respond to the start or control request in a
>  timely fashion. (0x41d)
>
> Wrapper.log (complete file):
> STATUS | wrapper  | 2011/05/09 10:31:59 | Starting the SCHECK_DZA_PRD
> service...
> ERROR  | wrapper  | 2011/05/09 10:31:59 | Unable to start the 
SCHECK_DZA_PRD
> service - The service did not respond to the start or control request in 
a
> timely fashion. (0x41d)
>
> G:\>sc start SCheck_DZA_PRD
> [SC] StartService FAILED 1053:
>
> The service did not respond to the start or control request in a timely
> fashion.
>
> Wrapper.log: (Empty)
>
> Hope I didn't screwed the wrapper.conf. Here it is:
>
> Things look good when starting in console mode:
>
>         G:\>G:\SCheck_DZA_PRD\wrapper.exe -c
> G:\SCheck_DZA_PRD\\conf\wrapper.conf
>
> Wrapper.log
>
> Hope you have an idea.
> We (me and another one of the old Windows dinosaurs) spent almost 4 days 
on
> this now and feel a bit lost.
>
> Cheers
> Peter
>
>
>
>
>
>
> From:        Leif Mortenson <lei...@ta...>
> To:        wra...@li...
> Date:        09-05-11 11:40
> Subject:        Re: [Wrapper-user] Wrapper 
"StartServiceControlDispatcher
> failed!"
> ________________________________
>
>
> Peter,
> The "wrapper -s conf" command is used by the Service Manager to launch
> the Wrapper as a service.  That should never have worked from the
> command line.  You would see something like this:
>
> ---
> Attempting to start Test Wrapper Sample Application as an NT service.
>
> Calling StartServiceCtrlDispatcher...please wait.
>
> StartServiceControlDispatcher failed!
>
> The -s and --service commands should only be called by the Windows
> ServiceManager to control the Wrapper as a service, and is not
> designed to be run manually by the user.
>
> For help, type
> bin\wrapper -?
> ---
>
> "wrapper -t conf" is what you want to start the service.
>
> I am not sure what could be causing the failed to start problem.  That
> message is usually shown by the Windows Service Manager if the service
> takes too long to start without reporting its status, but you said
> that it happens almost immediately.
>
> Could you set the wrapper.debug=true property and then send a
> wrapper.log file that shows this happening?   That might give me a bit
> more information to be able to help further.
>
> Cheers,
> Leif
>
> On Mon, May 9, 2011 at 5:49 PM, Peter Beecken <pbe...@am...> 
wrote:
>> Dear all,
>>
>> Some wrapper services are not starting on our Windows cluster.
>> They do not even start up as a local service.
>> The log file tells us "StartServiceControlDispatcher failed!"
>>
>> We have a Windows cluster with 5 physical nodes for monitoring 
purposes.
>> There are 13 resource groups.
>> 8 of them run home made Java services using Wrapper 3.2.3.
>> These resource groups also have a Tivoli backup client.
>> Originally all 8 monitoring groups ran on servers 3 and 4.
>> For better load balancing we decided to also use Server1/2/5 for
>> monitoring.
>>
>> I replicated all service related registry entries by script, updated 
the
>> cluster config to include the new nodes and moved some groups from the
>> old servers (3 and 4).
>>
>> After replicating the service definitions to Server1,2 and 5 the 
situation
>> on resource looks like:
>>
>> Service/Node    SERVER1 SERVER2 SERVER3 SERVER4  SERVER4
>> SCHECK_DZA_PRD   OK       OK       OK      OK    FAILED
>> SCHECK_MONOFMOG  OK     FAILED     OK      OK    FAILED
>> SCHECK_OPODO     OK       OK       OK      OK      OK
>> SCHECK_ORA       OK       OK       OK      OK    FAILED
>> SCHECK_UNIX5    FAILED   FAILED    OK      OK    FAILED
>> SCHECK_UNIX6    FAILED    OK       OK      OK    FAILED
>> SCHECK_VCS       OK       OK       OK      OK    FAILED
>>
>> FAILED meaning that the the service did not start.
>> ERROR  | wrapper  | 2011/05/09 08:14:09 | Unable to start the
>>    SCHECK_DZA_PRD service -
>>    The service did not respond to the start
>>    or control request in a timely fashion. (0x41d)
>>
>> Message shows up immediately, few milliseconds delay only.
>>
>> Wrapper services are started as:
>>
>>   G:\SCheck_DZA_PRD\wrapper.exe -s G:\SCheck_DZA_PRD\\conf\wrapper.conf
>>
>>   For some reason -s was used in the past and worked.
>>   Changed it to -t but results did not change.
>>
>> As all resources of a service are in one folder, I copied the folder to
>> local disk, changed the service command line (regedit and wrapper.conf)
>> to reflect the correct folder and could start the service.
>>
>> Copying the folder to another SAN drive resulted in a working service.
>>
>> Copying/renaming the folder on the same SAN drive ended up with the
>> above error message.
>>
>> Configuration:
>> Server   OS          System         CPUs VCPUs  Processor
>> Mem(GB)
>> SERVER1  2003EE SP2  ProLiant DL380 G5 2     8  x86 Family 6
>>          5.2.3790                               Model 15 Stepping 11
>> 16
>>                                                 GenuineIntel ~2666 Mhz
>> SERVER2  2003EE SP2  ProLiant DL380 G5 2     8  x86 Family 6
>>          5.2.3790                               Model 15 Stepping 11
>>                                                 GenuineIntel ~2666 Mhz
>> 16
>> SERVER3  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
>>          5.2.3790                               Model 15 Stepping 11
>>                                                 GenuineIntel ~2933 Mhz"
>>  16
>> SERVER4  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
>>          5.2.3790                               Model 15 Stepping 11
>>                                                 GenuineIntel ~2933 Mhz"
>>  16
>> SERVER5  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
>>          5.2.3790                               Model 29 Stepping 1
>>                                                 GenuineIntel ~2400 Mhz"
>> 8
>>
>> All servers use Veritas and SAN devices (EMC SYMMETRIX) for drives G, 
H,
>> ...
>> Local drives are C: D: E: (used for Windows and S/W not related to
>> Wrapper).
>> Wrapper Version 3.2.3 being used for all Wrapper services.
>> Also tried 3.8.7 with exactly same results.
>>
>> Any idea what I might try next?
>
> 
------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>
>
>
> IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only 
for
> the use of the individual or entity shown above as addressees. It may
> contain information which is privileged, confidential or otherwise 
protected
> from disclosure under applicable laws.  If the reader of this 
transmission
> is not the intended recipient, you are hereby notified that any
> dissemination, printing, distribution, copying, disclosure or the taking 
of
> any action in reliance on the contents of this information is strictly
> prohibited.  If you have received this transmission in error, please
> immediately notify us by reply e-mail or using the address below and 
delete
> the message and any attachments from your system.
>
> Amadeus Data Processing GmbH
> Geschäftsführer: Eberhard Haag
> Sitz der Gesellschaft: Erding
> HR München 48 199
> Berghamer Strasse 6
> 85435 Erding
> Germany
> 
------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user





IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only for 
the use of the individual or entity shown above as addressees. It may 
contain information which is privileged, confidential or otherwise 
protected from disclosure under applicable laws.  If the reader of this 
transmission is not the intended recipient, you are hereby notified that 
any dissemination, printing, distribution, copying, disclosure or the 
taking of any action in reliance on the contents of this information is 
strictly prohibited.  If you have received this transmission in error, 
please immediately notify us by reply e-mail or using the address below 
and delete the message and any attachments from your system. 

Amadeus Data Processing GmbH 
Geschäftsführer: Eberhard Haag 
Sitz der Gesellschaft: Erding 
HR München 48 199 
Berghamer Strasse 6 
85435 Erding 
Germany

Re: [Wrapper-user] Sticky-Bit

[Roberto E. <rob...@ta...>]

Hello Walter,

Running the wrapper with the setuid set is not supported as it is a
potential security risk and the behavior is different across Linux and
Unix systems.
It is also depends which Java binary you are using (Sun Java, OpenJDK
etc.) and of course the setuid policy, for example, sometimes file
systems are mounted disabling the sticky bit.

I have also read setuid works different with multi threaded programs
as the setuid permissions are not set and this potentially can be a
problem with Java, sorry I have no more information or experience
about this but it is something to be kept in mind.

I would recommend you to launch your JVM as root, probably as a daemon
if possible so it behaves as a Unix service. Or maybe add a "sudo"
rule so a normal user can run your Java application.

If you still want to go ahead then with a bit of work you can launch
the wrapper with the sticky bit, the behavior is unpredictable as it
depends on how your system is setup, your shared libraries, etc.

Let me give you an example on how to get this working in Natty (Ubuntu 11.04).

First, the sticky bit needs to be set in the wrapper binary as it is
the one launching the JVM.

chown root:root bin/wrapper
chmod ug+s bin/wrapper


Running "file bin/wrapper" should show the sticky bit is set for user and group.

wrapper: setuid setgid ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.0,
not stripped


Now, setuid executables completely ignore LD_LIBRARY_PATH for security
reasons and Java uses this to resolve the dependencies.
If you run a "ldd" on the java binary, you will see there are some
missing libraries for OpenJDK,

$ ldd /usr/bin/java
	linux-vdso.so.1 =>  (0x00007fff91fff000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7197c9c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7197a7e000)
	libjli.so => not found
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7197879000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f71974e5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7197ed6000)

In this case, libjli.so is not found but normally is not a problem as
this get resolved on execution.
Now, if I try to run my application with the wrapper without resolving
this, I will get the following output

wrapper  | JVM exited while loading the application.
jvm 1    | java: error while loading shared libraries: libjli.so:
cannot open shared object file: No such file or directory

To solve this, I just need to add the library to my "/etc/ld.so.conf"
file. For natty, I add a new file called "java.conf" in
"/etc/ld.so.conf" with the path holding the missing shared library.

root@tanuki:/etc/ld.so.conf.d# cat java.conf
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/jli

Then refresh the ld.so.cache

# ldconfig -v

The missing library now it is resolved

$ ldd /usr/bin/java
	linux-vdso.so.1 =>  (0x00007fff8ac31000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007effc7323000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007effc7105000)
	libjli.so => /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/jli/libjli.so
(0x00007effc6eff000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effc6cfb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effc6967000)
	/lib64/ld-linux-x86-64.so.2 (0x00007effc755d000)

Running my application using the java service wrapper works now and
the effective permissions for the JVM are now set to 0 (root).

This can be checked easily checking the status for the java process

$ cat /proc/<java-pid>/status
Name:	java
State:	S (sleeping)
Tgid:	6063
Pid:	6063
PPid:	6061
TracerPid:	0
Uid:	1000	0	0	0
Gid:	1000	0	0	0
FDSize:	64


Uid and Gid are 0 (root) now, the initial uid and gid was 1000.


Good luck.
Roberto

On Tue, May 10, 2011 at 2:38 AM, Walter Pfleiderer
<wpf...@t-...> wrote:
> Hello,
>
> I am in the situation, that a java-daemon will open a TCP-port
> lower 1024 and needs the sticky-bit to connect to the port under
> linux. Linux (RedHat) dont't allow to open a port lower than 1024
> without root-rights.
>
> During starting there are several processes, which are involved,
> so I don't know, which process must get the sticky bit.
>
> Please, can you tell me, which process must get the sticky-bit:
>
> * the starting script
> * the wrapper daemon
> * the jar-file, which contains the code for the TCP-Port
> * the java JVM
>
> Thanks for all responses.
>
> Walter Pfleiderer
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>



-- 
Roberto Espinoza
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel/Fax: +81-3-3878-3211
http://www.tanukisoftware.com
rob...@ta...

[Wrapper-user] Sticky-Bit

[Walter P. <wpf...@t-...>]

Hello,

I am in the situation, that a java-daemon will open a TCP-port
lower 1024 and needs the sticky-bit to connect to the port under
linux. Linux (RedHat) dont't allow to open a port lower than 1024
without root-rights.

During starting there are several processes, which are involved,
so I don't know, which process must get the sticky bit.

Please, can you tell me, which process must get the sticky-bit:

* the starting script
* the wrapper daemon
* the jar-file, which contains the code for the TCP-Port
* the java JVM

Thanks for all responses.

Walter Pfleiderer

Re: [Wrapper-user] Wrapper "StartServiceControlDispatcher failed!"

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

Peter,
The "wrapper -s conf" command is used by the Service Manager to launch
the Wrapper as a service.  That should never have worked from the
command line.  You would see something like this:

---
Attempting to start Test Wrapper Sample Application as an NT service.

Calling StartServiceCtrlDispatcher...please wait.

StartServiceControlDispatcher failed!

The -s and --service commands should only be called by the Windows
ServiceManager to control the Wrapper as a service, and is not
designed to be run manually by the user.

For help, type
bin\wrapper -?
---

"wrapper -t conf" is what you want to start the service.

I am not sure what could be causing the failed to start problem.  That
message is usually shown by the Windows Service Manager if the service
takes too long to start without reporting its status, but you said
that it happens almost immediately.

Could you set the wrapper.debug=true property and then send a
wrapper.log file that shows this happening?   That might give me a bit
more information to be able to help further.

Cheers,
Leif

On Mon, May 9, 2011 at 5:49 PM, Peter Beecken <pbe...@am...> wrote:
> Dear all,
>
> Some wrapper services are not starting on our Windows cluster.
> They do not even start up as a local service.
> The log file tells us "StartServiceControlDispatcher failed!"
>
> We have a Windows cluster with 5 physical nodes for monitoring purposes.
> There are 13 resource groups.
> 8 of them run home made Java services using Wrapper 3.2.3.
> These resource groups also have a Tivoli backup client.
> Originally all 8 monitoring groups ran on servers 3 and 4.
> For better load balancing we decided to also use Server1/2/5 for monitoring.
>
> I replicated all service related registry entries by script, updated the
> cluster config to include the new nodes and moved some groups from the
> old servers (3 and 4).
>
> After replicating the service definitions to Server1,2 and 5 the situation
> on resource looks like:
>
> Service/Node    SERVER1 SERVER2 SERVER3 SERVER4  SERVER4
> SCHECK_DZA_PRD   OK       OK       OK      OK    FAILED
> SCHECK_MONOFMOG  OK     FAILED     OK      OK    FAILED
> SCHECK_OPODO     OK       OK       OK      OK      OK
> SCHECK_ORA       OK       OK       OK      OK    FAILED
> SCHECK_UNIX5    FAILED   FAILED    OK      OK    FAILED
> SCHECK_UNIX6    FAILED    OK       OK      OK    FAILED
> SCHECK_VCS       OK       OK       OK      OK    FAILED
>
> FAILED meaning that the the service did not start.
> ERROR  | wrapper  | 2011/05/09 08:14:09 | Unable to start the
>    SCHECK_DZA_PRD service -
>    The service did not respond to the start
>    or control request in a timely fashion. (0x41d)
>
> Message shows up immediately, few milliseconds delay only.
>
> Wrapper services are started as:
>
>   G:\SCheck_DZA_PRD\wrapper.exe -s G:\SCheck_DZA_PRD\\conf\wrapper.conf
>
>   For some reason -s was used in the past and worked.
>   Changed it to -t but results did not change.
>
> As all resources of a service are in one folder, I copied the folder to
> local disk, changed the service command line (regedit and wrapper.conf)
> to reflect the correct folder and could start the service.
>
> Copying the folder to another SAN drive resulted in a working service.
>
> Copying/renaming the folder on the same SAN drive ended up with the
> above error message.
>
> Configuration:
> Server   OS          System         CPUs VCPUs  Processor           Mem(GB)
> SERVER1  2003EE SP2  ProLiant DL380 G5 2     8  x86 Family 6
>          5.2.3790                               Model 15 Stepping 11     16
>                                                 GenuineIntel ~2666 Mhz
> SERVER2  2003EE SP2  ProLiant DL380 G5 2     8  x86 Family 6
>          5.2.3790                               Model 15 Stepping 11
>                                                 GenuineIntel ~2666 Mhz   16
> SERVER3  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
>          5.2.3790                               Model 15 Stepping 11
>                                                 GenuineIntel ~2933 Mhz"  16
> SERVER4  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
>          5.2.3790                               Model 15 Stepping 11
>                                                 GenuineIntel ~2933 Mhz"  16
> SERVER5  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
>          5.2.3790                               Model 29 Stepping 1
>                                                 GenuineIntel ~2400 Mhz"   8
>
> All servers use Veritas and SAN devices (EMC SYMMETRIX) for drives G, H, ...
> Local drives are C: D: E: (used for Windows and S/W not related to Wrapper).
> Wrapper Version 3.2.3 being used for all Wrapper services.
> Also tried 3.8.7 with exactly same results.
>
> Any idea what I might try next?

[Wrapper-user] Wrapper "StartServiceControlDispatcher failed!"

[Peter B. <pbe...@am...>]

Dear all,

Some wrapper services are not starting on our Windows cluster.
They do not even start up as a local service.
The log file tells us "StartServiceControlDispatcher failed!"

We have a Windows cluster with 5 physical nodes for monitoring purposes.
There are 13 resource groups.
8 of them run home made Java services using Wrapper 3.2.3.
These resource groups also have a Tivoli backup client.
Originally all 8 monitoring groups ran on servers 3 and 4.
For better load balancing we decided to also use Server1/2/5 for 
monitoring.

I replicated all service related registry entries by script, updated the
cluster config to include the new nodes and moved some groups from the
old servers (3 and 4).

After replicating the service definitions to Server1,2 and 5 the situation
on resource looks like:

Service/Node    SERVER1 SERVER2 SERVER3 SERVER4  SERVER4
SCHECK_DZA_PRD   OK       OK       OK      OK    FAILED
SCHECK_MONOFMOG  OK     FAILED     OK      OK    FAILED
SCHECK_OPODO     OK       OK       OK      OK      OK
SCHECK_ORA       OK       OK       OK      OK    FAILED
SCHECK_UNIX5    FAILED   FAILED    OK      OK    FAILED
SCHECK_UNIX6    FAILED    OK       OK      OK    FAILED
SCHECK_VCS       OK       OK       OK      OK    FAILED

FAILED meaning that the the service did not start.
ERROR  | wrapper  | 2011/05/09 08:14:09 | Unable to start the
   SCHECK_DZA_PRD service -
   The service did not respond to the start
   or control request in a timely fashion. (0x41d)

Message shows up immediately, few milliseconds delay only.

Wrapper services are started as:

  G:\SCheck_DZA_PRD\wrapper.exe -s G:\SCheck_DZA_PRD\\conf\wrapper.conf

  For some reason -s was used in the past and worked.
  Changed it to -t but results did not change.

As all resources of a service are in one folder, I copied the folder to
local disk, changed the service command line (regedit and wrapper.conf)
to reflect the correct folder and could start the service.

Copying the folder to another SAN drive resulted in a working service.

Copying/renaming the folder on the same SAN drive ended up with the
above error message.

Configuration:
Server   OS          System         CPUs VCPUs  Processor Mem(GB)
SERVER1  2003EE SP2  ProLiant DL380 G5 2     8  x86 Family 6
         5.2.3790                               Model 15 Stepping 11 16
                                                GenuineIntel ~2666 Mhz
SERVER2  2003EE SP2  ProLiant DL380 G5 2     8  x86 Family 6
         5.2.3790                               Model 15 Stepping 11
                                                GenuineIntel ~2666 Mhz 16
SERVER3  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
         5.2.3790                               Model 15 Stepping 11
                                                GenuineIntel ~2933 Mhz" 16
SERVER4  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
         5.2.3790                               Model 15 Stepping 11
                                                GenuineIntel ~2933 Mhz" 16
SERVER5  2003EE SP2  ProLiant DL580 G5 4    16  x86 Family 6
         5.2.3790                               Model 29 Stepping 1
                                                GenuineIntel ~2400 Mhz" 8

All servers use Veritas and SAN devices (EMC SYMMETRIX) for drives G, H, 
...
Local drives are C: D: E: (used for Windows and S/W not related to 
Wrapper).
Wrapper Version 3.2.3 being used for all Wrapper services.
Also tried 3.8.7 with exactly same results.

Any idea what I might try next?





IMPORTANT  -  CONFIDENTIALITY  NOTICE  - This e-mail is intended only for 
the use of the individual or entity shown above as addressees. It may 
contain information which is privileged, confidential or otherwise 
protected from disclosure under applicable laws.  If the reader of this 
transmission is not the intended recipient, you are hereby notified that 
any dissemination, printing, distribution, copying, disclosure or the 
taking of any action in reliance on the contents of this information is 
strictly prohibited.  If you have received this transmission in error, 
please immediately notify us by reply e-mail or using the address below 
and delete the message and any attachments from your system. 

Amadeus Data Processing GmbH 
Geschäftsführer: Eberhard Haag 
Sitz der Gesellschaft: Erding 
HR München 48 199 
Berghamer Strasse 6 
85435 Erding 
Germany

Re: [Wrapper-user] Launched daemon on Mac OSX appears in Dock and in Menu Bar

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

Brian,
Does your application have a GUI that is being displayed?   I just
checked and confirmed that console based applications do not cause an
icon to be displayed.

For Swing applications, you can handle the close even when the user
clicks to close the window using the windowClosing method of a
WindowListener.   But I tried it and the menu bar's Quit choice does
not use that.  Nor does it appear to be killing it with a TERM signal.

Digging around a bit more.  I think I found what you want:
http://stackoverflow.com/questions/2061194/swing-on-osx-how-to-trap-command-q
http://developer.apple.com/library/mac/#samplecode/OSXAdapter/Introduction/Intro.html

I have not had a chance to try it out yet, but it looks like this will
actually make it possible to cancel the CMD-Q request.   We will look
into to whether or not it makes sense to add this into the core
Wrapper for a future release.

Please let me know how this works for you.

Cheers,
Leif

On Thu, May 5, 2011 at 1:36 AM, brian mcgann <br...@gi...> wrote:
> I am using wrapper-32-3.5.7.jar and am successfully launching my daemon on
> Mac OS X Snow Leopard, however when running, an icon for the daemon appears
> on the dock and also appears on the menu bar, complete with a 'Quit' menu
> item.  How can I avoid this?
>
> Thanks,
>
> Brian McGann

Re: [Wrapper-user] Wrapper restarts JVM when no response from server

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

Gaurav,
Restarts can be caused by a number of things.  Without seeing the logs, I
don't have any way of helping sorry.

Cheers,
Lei

On Fri, May 6, 2011 at 1:42 PM, Gaurav Pgoel <gau...@tc...> wrote:

>
> Hello,
>
> I am sorry to provide you with previous logs as it has rolled out. I only
> have jvm4 logs with me.
> Leif, is there any other workaround to prevent this restart?
>
> Regards,
> Gaurav Goel
> Tata Consultancy Services
> Mailto: gau...@tc...
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________
>
>
>  From:
> Leif Mortenson <lei...@ta...>
> To:
> wra...@li...
> Date: 05/06/2011 09:54 AM Subject: Re: [Wrapper-user] Wrapper restarts JVM
> when no response from server
> ------------------------------
>
>
>
> Gaurav,
> The restart in the log you sent me was definitely caused by an external
> source restarting the service.  You can see how the Wrapper itself was
> stopped and then started again 3 minutes later.
>
> ---
> STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the
> service.
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
> hidden successfully.
> STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service
> ---
>
> Prior to the shutdown at 2011/05/03 21:52:18 however you could see that the
> Wrapper was running its 4th JVM.  This means that the JVM had been restarted
> 3 times for some other reason.   If you could send me the full log file that
> shows those restarts in a direct email I will take a look at what caused
> them.   Those may be because of a timeout but I am unable to say from what
> you sent me.
>
> Cheers,
> Leif
>
> On Fri, May 6, 2011 at 1:04 PM, Gaurav Pgoel <*gau...@tc...*<gau...@tc...>>
> wrote:
>
> Thank you for the replies.
> Leif, you mean the service was restarted and we can ignore the fact that
> the JVM was hung or not responding?
>
> There is one more observation that i want to share. We have seen this
> similar behavior on one more client machine. This raises a doubt as to
> whether both places did someone restart the service?
>
> Regards.
> Gaurav Goel
> Tata Consultancy Services
> Mailto: *gau...@tc...* <gau...@tc...>
> Website: *http://www.tcs.com* <http://www.tcs.com/>
>
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________
>
>   From: Leif Mortenson <*lei...@ta...*<lei...@ta...>
> >  To: *wra...@li...*<wra...@li...>
> Date: 05/05/2011 08:14 PM  Subject: Re: [Wrapper-user] Wrapper restarts
> JVM when no response from server
>
>  ------------------------------
>
>
>
>
> Gaurav,
> Thank you for the detailed message.  It makes it easy to respond.
>
> In your case, the Wrapper is shutting down because the Windows Service
> Manager has sent in a stop command:
>
> DEBUG  | wrapperp | 2011/05/03 21:52:13 | read a packet PING : ping
> DEBUG  | wrapper  | 2011/05/03 21:52:16 |   SERVICE_CONTROL_STOP
>
> When the Wrapper stops, the Service Manager is starting it again
> almost immediately.
>
> STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the
> service.
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
> hidden successfully.
> STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service
>
> This makes me think that someone pressed the Service Restart button in
> the service control manager.  But I am only guessing as we do not have
> any way of telling what initiated such a restart.
>
> At the time that the Wrapper shuts down however, I do see that you are
> on the 4th Java invocation since the Wrapper was launched.  The log
> fragment that you sent does not include any of the 3 restarts that
> took place so I am unable to see what the circumstances were around
> those restarts.    Could you please locate one of them in your logs
> and then send me a few minutes before the restart through a minute or
> so after?
>
> I also see that you are using 3.5.4.  The 3.5.8 version that we just
> released contains some improvements which will prevent unneeded JVM
> restarts on heavily IO loaded systems.  I have not seen anything yet
> to show that that is the problem however.
>
> Cheers,
> Leif
>
> On Thu, May 5, 2011 at 7:48 PM, Gaurav Pgoel <*gau...@tc...*<gau...@tc...>>
> wrote:
> >
> > Hi,
> >
> > I am using Wrapper 3.5.4. I have written a java code and running it as
> java
> > wrapper service on Windows NT machine.
> > I have a code to uplaod files from client machine (on which service is
> > installed) to server.
> > Sometimes, it happens that the upload takes time say 5 - 10 minutes to
> > upload a file. In the meantime, there is no response from server to the
> > client.
> >
> > In this situation, I assume, that my wrapper service restarts JVM
> thinking
> > that the jvm is hung.
> >
> > Due to this, there is duplicate upload happening. To avoid this, i am
> > thinking of increasing wrapper ping interval to say 300 seconds. What do
> you
> > think guys?
> >
> > Below is the wrapper.conf file contents:
> <snip>
> >
> *******************************************************************************************
> >
> > Also written below is the system logs;
> >
> *******************************************************************************************
> <snip>
> >
> *******************************************************************************************
> >
> >
> > Guys what your views on this? Is this really because Wrapper thinks that
> the
> > JVM is hung? Or is it because of some other reason?
> >
> > Thanks in advance to all.
> >
> > Regards,
> > Gaurav Goel
> > Tata Consultancy Services
> > Mailto: *gau...@tc...* <gau...@tc...>
> > Website: *http://www.tcs.com* <http://www.tcs.com/>
>
>

Re: [Wrapper-user] Wrapper restarts JVM when no response from server

[Gaurav P. <gau...@tc...>]

Hello,

I am sorry to provide you with previous logs as it has rolled out. I only 
have jvm4 logs with me.
Leif, is there any other workaround to prevent this restart?

Regards,
Gaurav Goel
Tata Consultancy Services
Mailto: gau...@tc...
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________



From:
Leif Mortenson <lei...@ta...>
To:
wra...@li...
Date:
05/06/2011 09:54 AM
Subject:
Re: [Wrapper-user] Wrapper restarts JVM when no response from server



Gaurav,
The restart in the log you sent me was definitely caused by an external 
source restarting the service.  You can see how the Wrapper itself was 
stopped and then started again 3 minutes later.

---
STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the 
service.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
hidden successfully.
STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service
---

Prior to the shutdown at 2011/05/03 21:52:18 however you could see that 
the Wrapper was running its 4th JVM.  This means that the JVM had been 
restarted 3 times for some other reason.   If you could send me the full 
log file that shows those restarts in a direct email I will take a look at 
what caused them.   Those may be because of a timeout but I am unable to 
say from what you sent me.

Cheers,
Leif

On Fri, May 6, 2011 at 1:04 PM, Gaurav Pgoel <gau...@tc...> wrote:

Thank you for the replies. 
Leif, you mean the service was restarted and we can ignore the fact that 
the JVM was hung or not responding? 

There is one more observation that i want to share. We have seen this 
similar behavior on one more client machine. This raises a doubt as to 
whether both places did someone restart the service? 

Regards.
Gaurav Goel
Tata Consultancy Services
Mailto: gau...@tc...
Website: http://www.tcs.com

____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Outsourcing
____________________________________________ 


From: 
Leif Mortenson <lei...@ta...> 
To: 
wra...@li... 
Date: 
05/05/2011 08:14 PM 
Subject: 
Re: [Wrapper-user] Wrapper restarts JVM when no response from server





Gaurav,
Thank you for the detailed message.  It makes it easy to respond.

In your case, the Wrapper is shutting down because the Windows Service
Manager has sent in a stop command:

DEBUG  | wrapperp | 2011/05/03 21:52:13 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:52:16 |   SERVICE_CONTROL_STOP

When the Wrapper stops, the Service Manager is starting it again
almost immediately.

STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the 
service.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
hidden successfully.
STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service

This makes me think that someone pressed the Service Restart button in
the service control manager.  But I am only guessing as we do not have
any way of telling what initiated such a restart.

At the time that the Wrapper shuts down however, I do see that you are
on the 4th Java invocation since the Wrapper was launched.  The log
fragment that you sent does not include any of the 3 restarts that
took place so I am unable to see what the circumstances were around
those restarts.    Could you please locate one of them in your logs
and then send me a few minutes before the restart through a minute or
so after?

I also see that you are using 3.5.4.  The 3.5.8 version that we just
released contains some improvements which will prevent unneeded JVM
restarts on heavily IO loaded systems.  I have not seen anything yet
to show that that is the problem however.

Cheers,
Leif

On Thu, May 5, 2011 at 7:48 PM, Gaurav Pgoel <gau...@tc...> wrote:
>
> Hi,
>
> I am using Wrapper 3.5.4. I have written a java code and running it as 
java
> wrapper service on Windows NT machine.
> I have a code to uplaod files from client machine (on which service is
> installed) to server.
> Sometimes, it happens that the upload takes time say 5 - 10 minutes to
> upload a file. In the meantime, there is no response from server to the
> client.
>
> In this situation, I assume, that my wrapper service restarts JVM 
thinking
> that the jvm is hung.
>
> Due to this, there is duplicate upload happening. To avoid this, i am
> thinking of increasing wrapper ping interval to say 300 seconds. What do 
you
> think guys?
>
> Below is the wrapper.conf file contents:
<snip>
> 
*******************************************************************************************
>
> Also written below is the system logs;
> 
*******************************************************************************************
<snip>
> 
*******************************************************************************************
>
>
> Guys what your views on this? Is this really because Wrapper thinks that 
the
> JVM is hung? Or is it because of some other reason?
>
> Thanks in advance to all.
>
> Regards,
> Gaurav Goel
> Tata Consultancy Services
> Mailto: gau...@tc...
> Website: http://www.tcs.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user


=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

[Wrapper-user] AUTO: Neeraja Kollu is out of office (returning 05/09/2011)

[Neeraja K. <nee...@in...>]

I am out of the office until 05/09/2011.


Please contact the following people for any asistance required during my
absence.

MMC - Sadanand Poorajan
Mercedes-Benz - Srinivasa K Korada




Note: This is an automated response to your message  "Re: [Wrapper-user]
Wrapper restarts JVM when no response from server" sent on 6/5/11 9:34:34.

This is the only notification you will receive while this person is away.

Re: [Wrapper-user] Wrapper restarts JVM when no response from server

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

Gaurav,
The restart in the log you sent me was definitely caused by an external
source restarting the service.  You can see how the Wrapper itself was
stopped and then started again 3 minutes later.

---
STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the
service.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
hidden successfully.
STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service
---

Prior to the shutdown at 2011/05/03 21:52:18 however you could see that the
Wrapper was running its 4th JVM.  This means that the JVM had been restarted
3 times for some other reason.   If you could send me the full log file that
shows those restarts in a direct email I will take a look at what caused
them.   Those may be because of a timeout but I am unable to say from what
you sent me.

Cheers,
Leif

On Fri, May 6, 2011 at 1:04 PM, Gaurav Pgoel <gau...@tc...> wrote:

>
> Thank you for the replies.
> Leif, you mean the service was restarted and we can ignore the fact that
> the JVM was hung or not responding?
>
> There is one more observation that i want to share. We have seen this
> similar behavior on one more client machine. This raises a doubt as to
> whether both places did someone restart the service?
>
> Regards.
> Gaurav Goel
> Tata Consultancy Services
> Mailto: gau...@tc...
> Website: http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Outsourcing
> ____________________________________________
>
>
>  From: Leif Mortenson <lei...@ta...> To:
> wra...@li... Date: 05/05/2011 08:14 PM Subject: Re:
> [Wrapper-user] Wrapper restarts JVM when no response from server
> ------------------------------
>
>
>
> Gaurav,
> Thank you for the detailed message.  It makes it easy to respond.
>
> In your case, the Wrapper is shutting down because the Windows Service
> Manager has sent in a stop command:
>
> DEBUG  | wrapperp | 2011/05/03 21:52:13 | read a packet PING : ping
> DEBUG  | wrapper  | 2011/05/03 21:52:16 |   SERVICE_CONTROL_STOP
>
> When the Wrapper stops, the Service Manager is starting it again
> almost immediately.
>
> STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the
> service.
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
> DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
> hidden successfully.
> STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service
>
> This makes me think that someone pressed the Service Restart button in
> the service control manager.  But I am only guessing as we do not have
> any way of telling what initiated such a restart.
>
> At the time that the Wrapper shuts down however, I do see that you are
> on the 4th Java invocation since the Wrapper was launched.  The log
> fragment that you sent does not include any of the 3 restarts that
> took place so I am unable to see what the circumstances were around
> those restarts.    Could you please locate one of them in your logs
> and then send me a few minutes before the restart through a minute or
> so after?
>
> I also see that you are using 3.5.4.  The 3.5.8 version that we just
> released contains some improvements which will prevent unneeded JVM
> restarts on heavily IO loaded systems.  I have not seen anything yet
> to show that that is the problem however.
>
> Cheers,
> Leif
>
> On Thu, May 5, 2011 at 7:48 PM, Gaurav Pgoel <gau...@tc...> wrote:
> >
> > Hi,
> >
> > I am using Wrapper 3.5.4. I have written a java code and running it as
> java
> > wrapper service on Windows NT machine.
> > I have a code to uplaod files from client machine (on which service is
> > installed) to server.
> > Sometimes, it happens that the upload takes time say 5 - 10 minutes to
> > upload a file. In the meantime, there is no response from server to the
> > client.
> >
> > In this situation, I assume, that my wrapper service restarts JVM
> thinking
> > that the jvm is hung.
> >
> > Due to this, there is duplicate upload happening. To avoid this, i am
> > thinking of increasing wrapper ping interval to say 300 seconds. What do
> you
> > think guys?
> >
> > Below is the wrapper.conf file contents:
> <snip>
> >
> *******************************************************************************************
> >
> > Also written below is the system logs;
> >
> *******************************************************************************************
> <snip>
> >
> *******************************************************************************************
> >
> >
> > Guys what your views on this? Is this really because Wrapper thinks that
> the
> > JVM is hung? Or is it because of some other reason?
> >
> > Thanks in advance to all.
> >
> > Regards,
> > Gaurav Goel
> > Tata Consultancy Services
> > Mailto: gau...@tc...
> > Website: http://www.tcs.com
>
>

Re: [Wrapper-user] Wrapper restarts JVM when no response from server

[Gaurav P. <gau...@tc...>]

Thank you for the replies.
Leif, you mean the service was restarted and we can ignore the fact that 
the JVM was hung or not responding?

There is one more observation that i want to share. We have seen this 
similar behavior on one more client machine. This raises a doubt as to 
whether both places did someone restart the service?

Regards.
Gaurav Goel
Tata Consultancy Services
Mailto: gau...@tc...
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________



From:
Leif Mortenson <lei...@ta...>
To:
wra...@li...
Date:
05/05/2011 08:14 PM
Subject:
Re: [Wrapper-user] Wrapper restarts JVM when no response from server



Gaurav,
Thank you for the detailed message.  It makes it easy to respond.

In your case, the Wrapper is shutting down because the Windows Service
Manager has sent in a stop command:

DEBUG  | wrapperp | 2011/05/03 21:52:13 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:52:16 |   SERVICE_CONTROL_STOP

When the Wrapper stops, the Service Manager is starting it again
almost immediately.

STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the 
service.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
hidden successfully.
STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service

This makes me think that someone pressed the Service Restart button in
the service control manager.  But I am only guessing as we do not have
any way of telling what initiated such a restart.

At the time that the Wrapper shuts down however, I do see that you are
on the 4th Java invocation since the Wrapper was launched.  The log
fragment that you sent does not include any of the 3 restarts that
took place so I am unable to see what the circumstances were around
those restarts.    Could you please locate one of them in your logs
and then send me a few minutes before the restart through a minute or
so after?

I also see that you are using 3.5.4.  The 3.5.8 version that we just
released contains some improvements which will prevent unneeded JVM
restarts on heavily IO loaded systems.  I have not seen anything yet
to show that that is the problem however.

Cheers,
Leif

On Thu, May 5, 2011 at 7:48 PM, Gaurav Pgoel <gau...@tc...> wrote:
>
> Hi,
>
> I am using Wrapper 3.5.4. I have written a java code and running it as 
java
> wrapper service on Windows NT machine.
> I have a code to uplaod files from client machine (on which service is
> installed) to server.
> Sometimes, it happens that the upload takes time say 5 - 10 minutes to
> upload a file. In the meantime, there is no response from server to the
> client.
>
> In this situation, I assume, that my wrapper service restarts JVM 
thinking
> that the jvm is hung.
>
> Due to this, there is duplicate upload happening. To avoid this, i am
> thinking of increasing wrapper ping interval to say 300 seconds. What do 
you
> think guys?
>
> Below is the wrapper.conf file contents:
<snip>
> 
*******************************************************************************************
>
> Also written below is the system logs;
> 
*******************************************************************************************
<snip>
> 
*******************************************************************************************
>
>
> Guys what your views on this? Is this really because Wrapper thinks that 
the
> JVM is hung? Or is it because of some other reason?
>
> Thanks in advance to all.
>
> Regards,
> Gaurav Goel
> Tata Consultancy Services
> Mailto: gau...@tc...
> Website: http://www.tcs.com

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user


=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Re: [Wrapper-user] Wrapper restarts JVM when no response from server

[Efrain P. <efr...@ze...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <font face="Courier New">Hi!<br>
      <br>
      I think you could try using two threads.<br>
      One thread uploads the file while the other one serves to the
      wrapper as a keep alive in order to avoid the JVM shutdown.<br>
      <br>
      Best Regards!<br>
    </font>
    <div class="moz-signature"><br>
      <img src="cid:par...@ze..." border="0"></div>
    <br>
    El 05/05/2011 05:48 a.m., Gaurav Pgoel escribi&oacute;:
    <blockquote
cite="mid:OFA...@tc..."
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=us-ascii">
      <br>
      Hi, <br>
      <br>
      I am using Wrapper 3.5.4. I have written
      a java code and running it as java wrapper service on Windows NT
      machine. <br>
      I have a code to uplaod files from client
      machine (on which service is installed) to server. <br>
      Sometimes, it happens that the upload
      takes time say 5 - 10 minutes to upload a file. In the meantime,
      there
      is no response from server to the client. &nbsp; <br>
      <br>
      In this situation, I assume, that my
      wrapper service restarts JVM thinking that the jvm is hung. <br>
      <br>
      Due to this, there is duplicate upload
      happening. To avoid this, i am thinking of increasing wrapper ping
      interval
      to say 300 seconds. What do you think guys? <br>
      <br>
      Below is the wrapper.conf file contents: <br>
      *******************************************************************************************
      <br>
      wrapper.lang.folder=../lang <br>
      <br>
      #********************************************************************
      <br>
      # Wrapper Java Properties <br>
      #********************************************************************
      <br>
      # Java Application <br>
      # &nbsp;Locate the java binary on the
      system PATH: <br>
      wrapper.java.command=java <br>
      # &nbsp;Specify a specific java binary: <br>
      #set.JAVA_HOME=/java/path <br>
      #wrapper.java.command=%JAVA_HOME%/bin/java <br>
      <br>
      # Tell the Wrapper to log the full generated
      Java command line. <br>
      wrapper.java.command.loglevel=INFO <br>
      <br>
      # Java Main class. &nbsp;This class
      must implement the WrapperListener interface <br>
      # &nbsp;or guarantee that the WrapperManager
      class is initialized. &nbsp;Helper <br>
      # &nbsp;classes are provided to do this
      for you. &nbsp;See the Integration section <br>
      # &nbsp;of the documentation for details. <br>
      #wrapper.java.mainclass=com.auto.upload.client.AutoFileUpload <br>
      wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
      <br>
      <br>
      # Java Classpath (include wrapper.jar)
      &nbsp;Add class path elements as <br>
      # &nbsp;needed starting from 1 <br>
      wrapper.java.classpath.1=../lib/wrapper.jar <br>
      wrapper.java.classpath.2=../lib/auto-upload.jar <br>
      wrapper.java.classpath.3=../lib/log4j-1.2.11.jar <br>
      wrapper.java.classpath.4=../lib/commons-io-2.0.jar <br>
      # Java Library Path (location of Wrapper.DLL
      or libwrapper.so) <br>
      wrapper.java.library.path.1=../lib <br>
      <br>
      # Java Bits. &nbsp;On applicable platforms,
      tells the JVM to run in 32 or 64-bit mode. <br>
      wrapper.java.additional.auto_bits=TRUE <br>
      <br>
      wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE
      <br>
      <br>
      # Java Additional Parameters <br>
      #wrapper.java.additional.2=-Dorg.tanukisoftware.wrapper.WrapperSimpleApp.maxStartMainWait=300
      <br>
      <br>
      # Initial Java Heap Size (in MB) <br>
      #wrapper.java.initmemory=3 <br>
      <br>
      # Maximum Java Heap Size (in MB) <br>
      #wrapper.java.maxmemory=64 <br>
      <br>
      # Application parameters. &nbsp;Add
      parameters as needed starting from 1 <br>
      wrapper.app.parameter.1=com.nsdl.auto.upload.client.AutoFileUpload
      <br>
      <br>
      #********************************************************************
      <br>
      # Wrapper Logging Properties <br>
      #********************************************************************
      <br>
      # Enables Debug output from the Wrapper. <br>
      wrapper.debug=TRUE <br>
      <br>
      # Format of output for the console.
      &nbsp;(See docs for formats) <br>
      wrapper.console.format=PM <br>
      <br>
      # Log Level for console output. &nbsp;(See
      docs for log levels) <br>
      wrapper.console.loglevel=INFO <br>
      <br>
      # Log file to use for wrapper output
      logging. <br>
      wrapper.logfile=../nsdl-system.log <br>
      <br>
      # Format of output for the log file.
      &nbsp;(See docs for formats) <br>
      wrapper.logfile.format=LPTM <br>
      <br>
      # Log Level for log file output. &nbsp;(See
      docs for log levels) <br>
      wrapper.logfile.loglevel=INFO <br>
      <br>
      # Maximum size that the log file will
      be allowed to grow to before <br>
      # &nbsp;the log is rolled. Size is specified
      in bytes. &nbsp;The default value <br>
      # &nbsp;of 0, disables log rolling.
      &nbsp;May abbreviate with the 'k' (kb) or <br>
      # &nbsp;'m' (mb) suffix. &nbsp;For example:
      10m = 10 megabytes. <br>
      wrapper.logfile.maxsize=2m <br>
      <br>
      # Maximum number of rolled log files
      which will be allowed before old <br>
      # &nbsp;files are deleted. &nbsp;The
      default value of 0 implies no limit. <br>
      wrapper.logfile.maxfiles=10 <br>
      <br>
      # Log Level for sys/event log output.
      &nbsp;(See docs for log levels) <br>
      wrapper.syslog.loglevel=NONE <br>
      <br>
      #********************************************************************
      <br>
      # Wrapper General Properties <br>
      #********************************************************************
      <br>
      # Allow for the use of non-contiguous
      numbered properties <br>
      wrapper.ignore_sequence_gaps=TRUE <br>
      <br>
      # Title to use when running as a console <br>
      wrapper.console.title=Automatic File
      Upload Service <br>
      <br>
      #********************************************************************
      <br>
      # Wrapper JVM Checks <br>
      #********************************************************************
      <br>
      # Detect DeadLocked Threads in the JVM.
      (Requires Standard Edition) <br>
      wrapper.check.deadlock=TRUE <br>
      wrapper.check.deadlock.interval=60 <br>
      wrapper.check.deadlock.action=RESTART <br>
      wrapper.check.deadlock.output=FULL <br>
      <br>
      # Out Of Memory detection. <br>
      wrapper.filter.trigger.1000=java.lang.OutOfMemoryError <br>
      wrapper.filter.action.1000=RESTART <br>
      wrapper.filter.message.1000=The JVM
      has run out of memory. <br>
      <br>
      #********************************************************************
      <br>
      # Wrapper Email Notifications. (Requires
      Professional Edition) <br>
      #********************************************************************
      <br>
      # Common Event Email settings. <br>
      #wrapper.event.default.email.debug=TRUE <br>
      #wrapper.event.default.email.smtp.host=&lt;SMTP_Host&gt; <br>
      #wrapper.event.default.email.smtp.port=25 <br>
      #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
Event
      Notification <br>
      #wrapper.event.default.email.sender=&lt;Sender
      email&gt; <br>
      #wrapper.event.default.email.recipient=&lt;Recipient
      email&gt; <br>
      <br>
      # Configure the log attached to event
      emails. <br>
      #wrapper.event.default.email.attach_log=TRUE <br>
      #wrapper.event.default.email.maillog.lines=50 <br>
      #wrapper.event.default.email.maillog.format=LPTM <br>
      #wrapper.event.default.email.maillog.loglevel=INFO <br>
      <br>
      # Enable specific event emails. <br>
      #wrapper.event.wrapper_start.email=TRUE <br>
      #wrapper.event.jvm_prelaunch.email=TRUE <br>
      #wrapper.event.jvm_start.email=TRUE <br>
      #wrapper.event.jvm_started.email=TRUE <br>
      #wrapper.event.jvm_deadlock.email=TRUE <br>
      #wrapper.event.jvm_stop.email=TRUE <br>
      #wrapper.event.jvm_stopped.email=TRUE <br>
      #wrapper.event.jvm_restart.email=TRUE <br>
      #wrapper.event.jvm_failed_invocation.email=TRUE <br>
      #wrapper.event.jvm_max_failed_invocations.email=TRUE <br>
      #wrapper.event.jvm_kill.email=TRUE <br>
      #wrapper.event.jvm_killed.email=TRUE <br>
      #wrapper.event.jvm_unexpected_exit.email=TRUE <br>
      #wrapper.event.wrapper_stop.email=TRUE <br>
      <br>
      # Specify custom mail content <br>
      wrapper.event.jvm_restart.email.body=The
      JVM was restarted.\n\nPlease check on its status.\n <br>
      <br>
      #********************************************************************
      <br>
      # Wrapper Windows NT/2000/XP Service
      Properties <br>
      #********************************************************************
      <br>
      # WARNING - Do not modify any of these
      properties when an application <br>
      # &nbsp;using this configuration file
      has been installed as a service. <br>
      # &nbsp;Please uninstall the service
      before modifying this section. &nbsp;The <br>
      # &nbsp;service can then be reinstalled. <br>
      <br>
      # Name of the service <br>
      wrapper.name=Automatic File Upload <br>
      <br>
      # Display name of the service <br>
      wrapper.displayname=Automatic File Upload
      Service <br>
      <br>
      # Description of the service <br>
      wrapper.description=auto file upload <br>
      <br>
      # Service dependencies. &nbsp;Add dependencies
      as needed starting from 1 <br>
      wrapper.ntservice.dependency.1= <br>
      <br>
      # Mode in which the service is installed.
      &nbsp;AUTO_START, DELAY_START or DEMAND_START <br>
      wrapper.ntservice.starttype=AUTO_START <br>
      <br>
      # Allow the service to interact with
      the desktop. <br>
      wrapper.ntservice.interactive=true <br>
      <br>
      *******************************************************************************************
      <br>
      <br>
      Also written below is the system logs; <br>
      *******************************************************************************************
      <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:33 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:33 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:33 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:51:34 | &nbsp; SERVICE_CONTROL_INTERROGATE <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:34 | send a packet SERVICE_CONTROL_CODE : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:34 | WrapperManager Debug: Received a packet
      SERVICE_CONTROL_CODE
      : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:34 | WrapperManager Debug: ServiceControlCode from Wrapper
      with code
      4 <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:37 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:37 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:37 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:37 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:41 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:42 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:42 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:42 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:51:45 | &nbsp; SERVICE_CONTROL_INTERROGATE <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:45 | send a packet SERVICE_CONTROL_CODE : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:46 | WrapperManager Debug: Received a packet
      SERVICE_CONTROL_CODE
      : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:46 | WrapperManager Debug: ServiceControlCode from Wrapper
      with code
      4 <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:46 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:46 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:46 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:46 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:50 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:50 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:50 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:50 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:55 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:55 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:55 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:55 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:51:57 | &nbsp; SERVICE_CONTROL_INTERROGATE <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:57 | send a packet SERVICE_CONTROL_CODE : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:57 | WrapperManager Debug: Received a packet
      SERVICE_CONTROL_CODE
      : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:57 | WrapperManager Debug: ServiceControlCode from Wrapper
      with code
      4 <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:59 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:59 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:51:59 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:51:59 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:04 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:04 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:04 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:04 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:08 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:08 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:08 | WrapperManager Debug: Send a packet PING : ping <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:08 | read a packet PING : ping <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:52:09 | &nbsp; SERVICE_CONTROL_INTERROGATE <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:09 | send a packet SERVICE_CONTROL_CODE : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:09 | WrapperManager Debug: Received a packet
      SERVICE_CONTROL_CODE
      : 4 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:09 | WrapperManager Debug: ServiceControlCode from Wrapper
      with code
      4 <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:13 | send a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:13 | WrapperManager Debug: Received a packet PING : ping <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:13 | WrapperManager Debug: Send a packet PING : ping <br>
      <b>DEBUG &nbsp;| wrapperp | 2011/05/03
        21:52:13 | read a packet PING : ping</b> <br>
      <b>DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
        21:52:16 | &nbsp; SERVICE_CONTROL_STOP</b> <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:16 | send a packet SERVICE_CONTROL_CODE : 1 <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:52:16 | wrapperStopProcess(0) called. <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:52:16 | Sending stop signal to JVM <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:16 | send a packet STOP : NULL <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Received a packet
      SERVICE_CONTROL_CODE
      : 1 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: ServiceControlCode from Wrapper
      with code
      1 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Received a packet STOP : <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Thread, Wrapper-Connection,
      handling the
      shutdown process. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: calling listener.stop() <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Waiting for WrapperListener.stop
      runner
      thread to complete. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: WrapperListener.stop runner
      thread started. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperSimpleApp Debug: stop(0) <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: WrapperListener.stop runner
      thread stopped. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: returned from listener.stop()
      -&gt; 0 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: shutdownJVM(0) Thread:
      Wrapper-Connection <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: wait for 0 shutdown locks to be
      released. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Send a packet STOPPED : 0 <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Stopped checking for control
      events. <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:16 | read a packet STOPPED : 0 <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:52:16 | JVM signaled that it was stopped. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:16 | WrapperManager Debug: Closing backend socket. <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:16 | socket read no code (closed?). <br>
      DEBUG &nbsp;| wrapperp | 2011/05/03
      21:52:16 | closing backend socket. <br>
      INFO &nbsp; | jvm 4 &nbsp; &nbsp;| 2011/05/03
      21:52:17 | WrapperManager Debug: calling System.exit(0) <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:52:17 | JVM process exited with a code of 0, leaving the
      wrapper exit
      code set to 0. <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:52:17 | JVM exited normally. <br>
      STATUS | wrapper &nbsp;| 2011/05/03
      21:52:18 | &lt;-- Wrapper Stopped <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Allocating a console for the service. <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Found console window. <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Wrapper console window hidden successfully. <br>
      STATUS | wrapper &nbsp;| 2011/05/03
      21:55:16 | --&gt; Wrapper Started as Service <br>
      STATUS | wrapper &nbsp;| 2011/05/03
      21:55:16 | Java Service Wrapper Community Edition 32-bit 3.5.4 <br>
      STATUS | wrapper &nbsp;| 2011/05/03
      21:55:16 | &nbsp; Copyright (C) 1999-2010 Tanuki Software, Ltd. All
      Rights
      Reserved. <br>
      STATUS | wrapper &nbsp;| 2011/05/03
      21:55:16 | &nbsp; &nbsp; <a moz-do-not-send="true"
        href="http://wrapper.tanukisoftware.com/">
        http://wrapper.tanukisoftware.com </a>
      <br>
      STATUS | wrapper &nbsp;| 2011/05/03
      21:55:16 | <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Release time: 2010/08/25 00:00:00 <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Build time: &nbsp; 2010/08/26 05:04:00 <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Timezone: &nbsp; &nbsp; India Standard Time (India Standard
      Time) Offset: -19800, hasDaylight: 0 <br>
      DEBUG &nbsp;| wrapper &nbsp;| 2011/05/03
      21:55:16 | Using tick timer. <br>
      ........................ <br>
      .......................... <br>
      <br>
      *******************************************************************************************
      <br>
      <br>
      <br>
      Guys what your views on this? Is this
      really because Wrapper thinks that the JVM is hung? Or is it
      because of
      some other reason? <br>
      <br>
      Thanks in advance to all. <br>
      <br>
      Regards,<br>
      Gaurav Goel<br>
      Tata Consultancy Services<br>
      Mailto: <a class="moz-txt-link-abbreviated" href="mailto:gau...@tc...">gau...@tc...</a><br>
      Website: <a moz-do-not-send="true" href="http://www.tcs.com/">
        http://www.tcs.com </a> <br>
      ____________________________________________<br>
      Experience certainty. &nbsp; &nbsp; &nbsp; &nbsp;IT Services<br>
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
      &nbsp; &nbsp; &nbsp; &nbsp;Business Solutions<br>
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
      &nbsp; &nbsp; &nbsp; &nbsp;Outsourcing<br>
      ____________________________________________
      <pre>=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


</pre>
    </blockquote>
  </body>
</html>

Re: [Wrapper-user] Wrapper restarts JVM when no response from server

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

Gaurav,
Thank you for the detailed message.  It makes it easy to respond.

In your case, the Wrapper is shutting down because the Windows Service
Manager has sent in a stop command:

DEBUG  | wrapperp | 2011/05/03 21:52:13 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:52:16 |   SERVICE_CONTROL_STOP

When the Wrapper stops, the Service Manager is starting it again
almost immediately.

STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the service.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window
hidden successfully.
STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service

This makes me think that someone pressed the Service Restart button in
the service control manager.  But I am only guessing as we do not have
any way of telling what initiated such a restart.

At the time that the Wrapper shuts down however, I do see that you are
on the 4th Java invocation since the Wrapper was launched.  The log
fragment that you sent does not include any of the 3 restarts that
took place so I am unable to see what the circumstances were around
those restarts.    Could you please locate one of them in your logs
and then send me a few minutes before the restart through a minute or
so after?

I also see that you are using 3.5.4.  The 3.5.8 version that we just
released contains some improvements which will prevent unneeded JVM
restarts on heavily IO loaded systems.  I have not seen anything yet
to show that that is the problem however.

Cheers,
Leif

On Thu, May 5, 2011 at 7:48 PM, Gaurav Pgoel <gau...@tc...> wrote:
>
> Hi,
>
> I am using Wrapper 3.5.4. I have written a java code and running it as java
> wrapper service on Windows NT machine.
> I have a code to uplaod files from client machine (on which service is
> installed) to server.
> Sometimes, it happens that the upload takes time say 5 - 10 minutes to
> upload a file. In the meantime, there is no response from server to the
> client.
>
> In this situation, I assume, that my wrapper service restarts JVM thinking
> that the jvm is hung.
>
> Due to this, there is duplicate upload happening. To avoid this, i am
> thinking of increasing wrapper ping interval to say 300 seconds. What do you
> think guys?
>
> Below is the wrapper.conf file contents:
<snip>
> *******************************************************************************************
>
> Also written below is the system logs;
> *******************************************************************************************
<snip>
> *******************************************************************************************
>
>
> Guys what your views on this? Is this really because Wrapper thinks that the
> JVM is hung? Or is it because of some other reason?
>
> Thanks in advance to all.
>
> Regards,
> Gaurav Goel
> Tata Consultancy Services
> Mailto: gau...@tc...
> Website: http://www.tcs.com

[Wrapper-user] Wrapper restarts JVM when no response from server

[Gaurav P. <gau...@tc...>]

Hi,

I am using Wrapper 3.5.4. I have written a java code and running it as 
java wrapper service on Windows NT machine.
I have a code to uplaod files from client machine (on which service is 
installed) to server.
Sometimes, it happens that the upload takes time say 5 - 10 minutes to 
upload a file. In the meantime, there is no response from server to the 
client. 

In this situation, I assume, that my wrapper service restarts JVM thinking 
that the jvm is hung.

Due to this, there is duplicate upload happening. To avoid this, i am 
thinking of increasing wrapper ping interval to say 300 seconds. What do 
you think guys?

Below is the wrapper.conf file contents:
*******************************************************************************************
wrapper.lang.folder=../lang

#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
#  Locate the java binary on the system PATH:
wrapper.java.command=java
#  Specify a specific java binary:
#set.JAVA_HOME=/java/path
#wrapper.java.command=%JAVA_HOME%/bin/java

# Tell the Wrapper to log the full generated Java command line.
wrapper.java.command.loglevel=INFO

# Java Main class.  This class must implement the WrapperListener 
interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
#wrapper.java.mainclass=com.auto.upload.client.AutoFileUpload
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/auto-upload.jar
wrapper.java.classpath.3=../lib/log4j-1.2.11.jar
wrapper.java.classpath.4=../lib/commons-io-2.0.jar
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib

# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 
64-bit mode.
wrapper.java.additional.auto_bits=TRUE

wrapper.java.additional.1=-Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE

# Java Additional Parameters
#wrapper.java.additional.2=-Dorg.tanukisoftware.wrapper.WrapperSimpleApp.maxStartMainWait=300

# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3

# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=com.nsdl.auto.upload.client.AutoFileUpload

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
wrapper.debug=TRUE

# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../nsdl-system.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=2m

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=10

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE

# Title to use when running as a console
wrapper.console.title=Automatic File Upload Service

#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=60
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL

# Out Of Memory detection.
wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
wrapper.filter.action.1000=RESTART
wrapper.filter.message.1000=The JVM has run out of memory.

#********************************************************************
# Wrapper Email Notifications. (Requires Professional Edition)
#********************************************************************
# Common Event Email settings.
#wrapper.event.default.email.debug=TRUE
#wrapper.event.default.email.smtp.host=<SMTP_Host>
#wrapper.event.default.email.smtp.port=25
#wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%] 
Event Notification
#wrapper.event.default.email.sender=<Sender email>
#wrapper.event.default.email.recipient=<Recipient email>

# Configure the log attached to event emails.
#wrapper.event.default.email.attach_log=TRUE
#wrapper.event.default.email.maillog.lines=50
#wrapper.event.default.email.maillog.format=LPTM
#wrapper.event.default.email.maillog.loglevel=INFO

# Enable specific event emails.
#wrapper.event.wrapper_start.email=TRUE
#wrapper.event.jvm_prelaunch.email=TRUE
#wrapper.event.jvm_start.email=TRUE
#wrapper.event.jvm_started.email=TRUE
#wrapper.event.jvm_deadlock.email=TRUE
#wrapper.event.jvm_stop.email=TRUE
#wrapper.event.jvm_stopped.email=TRUE
#wrapper.event.jvm_restart.email=TRUE
#wrapper.event.jvm_failed_invocation.email=TRUE
#wrapper.event.jvm_max_failed_invocations.email=TRUE
#wrapper.event.jvm_kill.email=TRUE
#wrapper.event.jvm_killed.email=TRUE
#wrapper.event.jvm_unexpected_exit.email=TRUE
#wrapper.event.wrapper_stop.email=TRUE

# Specify custom mail content
wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease 
check on its status.\n

#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.name=Automatic File Upload

# Display name of the service
wrapper.displayname=Automatic File Upload Service

# Description of the service
wrapper.description=auto file upload

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START, DELAY_START or 
DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=true

*******************************************************************************************

Also written below is the system logs;
*******************************************************************************************
INFO   | jvm 4    | 2011/05/03 21:51:33 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:33 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:33 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:51:34 |   SERVICE_CONTROL_INTERROGATE
DEBUG  | wrapperp | 2011/05/03 21:51:34 | send a packet 
SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:51:34 | WrapperManager Debug: Received a 
packet SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:51:34 | WrapperManager Debug: 
ServiceControlCode from Wrapper with code 4
DEBUG  | wrapperp | 2011/05/03 21:51:37 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:37 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:37 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:37 | read a packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:41 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:42 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:42 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:42 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:51:45 |   SERVICE_CONTROL_INTERROGATE
DEBUG  | wrapperp | 2011/05/03 21:51:45 | send a packet 
SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:51:46 | WrapperManager Debug: Received a 
packet SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:51:46 | WrapperManager Debug: 
ServiceControlCode from Wrapper with code 4
DEBUG  | wrapperp | 2011/05/03 21:51:46 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:46 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:46 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:46 | read a packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:50 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:50 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:50 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:50 | read a packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:55 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:55 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:55 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:55 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:51:57 |   SERVICE_CONTROL_INTERROGATE
DEBUG  | wrapperp | 2011/05/03 21:51:57 | send a packet 
SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:51:57 | WrapperManager Debug: Received a 
packet SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:51:57 | WrapperManager Debug: 
ServiceControlCode from Wrapper with code 4
DEBUG  | wrapperp | 2011/05/03 21:51:59 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:59 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:51:59 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:51:59 | read a packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:52:04 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:52:04 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:52:04 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:52:04 | read a packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:52:08 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:52:08 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:52:08 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:52:08 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:52:09 |   SERVICE_CONTROL_INTERROGATE
DEBUG  | wrapperp | 2011/05/03 21:52:09 | send a packet 
SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:52:09 | WrapperManager Debug: Received a 
packet SERVICE_CONTROL_CODE : 4
INFO   | jvm 4    | 2011/05/03 21:52:09 | WrapperManager Debug: 
ServiceControlCode from Wrapper with code 4
DEBUG  | wrapperp | 2011/05/03 21:52:13 | send a packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:52:13 | WrapperManager Debug: Received a 
packet PING : ping
INFO   | jvm 4    | 2011/05/03 21:52:13 | WrapperManager Debug: Send a 
packet PING : ping
DEBUG  | wrapperp | 2011/05/03 21:52:13 | read a packet PING : ping
DEBUG  | wrapper  | 2011/05/03 21:52:16 |   SERVICE_CONTROL_STOP
DEBUG  | wrapperp | 2011/05/03 21:52:16 | send a packet 
SERVICE_CONTROL_CODE : 1
DEBUG  | wrapper  | 2011/05/03 21:52:16 | wrapperStopProcess(0) called.
DEBUG  | wrapper  | 2011/05/03 21:52:16 | Sending stop signal to JVM
DEBUG  | wrapperp | 2011/05/03 21:52:16 | send a packet STOP : NULL
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Received a 
packet SERVICE_CONTROL_CODE : 1
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: 
ServiceControlCode from Wrapper with code 1
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Received a 
packet STOP : 
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Thread, 
Wrapper-Connection, handling the shutdown process.
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: calling 
listener.stop()
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Waiting 
for WrapperListener.stop runner thread to complete.
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: 
WrapperListener.stop runner thread started.
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperSimpleApp Debug: stop(0)
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: 
WrapperListener.stop runner thread stopped.
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: returned 
from listener.stop() -> 0
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: 
shutdownJVM(0) Thread: Wrapper-Connection
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: wait for 0 
shutdown locks to be released.
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Send a 
packet STOPPED : 0
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Stopped 
checking for control events.
DEBUG  | wrapperp | 2011/05/03 21:52:16 | read a packet STOPPED : 0
DEBUG  | wrapper  | 2011/05/03 21:52:16 | JVM signaled that it was 
stopped.
INFO   | jvm 4    | 2011/05/03 21:52:16 | WrapperManager Debug: Closing 
backend socket.
DEBUG  | wrapperp | 2011/05/03 21:52:16 | socket read no code (closed?).
DEBUG  | wrapperp | 2011/05/03 21:52:16 | closing backend socket.
INFO   | jvm 4    | 2011/05/03 21:52:17 | WrapperManager Debug: calling 
System.exit(0)
DEBUG  | wrapper  | 2011/05/03 21:52:17 | JVM process exited with a code 
of 0, leaving the wrapper exit code set to 0.
DEBUG  | wrapper  | 2011/05/03 21:52:17 | JVM exited normally.
STATUS | wrapper  | 2011/05/03 21:52:18 | <-- Wrapper Stopped
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Allocating a console for the 
service.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Found console window.
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Wrapper console window hidden 
successfully.
STATUS | wrapper  | 2011/05/03 21:55:16 | --> Wrapper Started as Service
STATUS | wrapper  | 2011/05/03 21:55:16 | Java Service Wrapper Community 
Edition 32-bit 3.5.4
STATUS | wrapper  | 2011/05/03 21:55:16 |   Copyright (C) 1999-2010 Tanuki 
Software, Ltd. All Rights Reserved.
STATUS | wrapper  | 2011/05/03 21:55:16 |     
http://wrapper.tanukisoftware.com
STATUS | wrapper  | 2011/05/03 21:55:16 | 
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Release time: 2010/08/25 
00:00:00
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Build time:   2010/08/26 
05:04:00
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Timezone:     India Standard 
Time (India Standard Time) Offset: -19800, hasDaylight: 0
DEBUG  | wrapper  | 2011/05/03 21:55:16 | Using tick timer.
........................
..........................

*******************************************************************************************


Guys what your views on this? Is this really because Wrapper thinks that 
the JVM is hung? Or is it because of some other reason?

Thanks in advance to all.

Regards,
Gaurav Goel
Tata Consultancy Services
Mailto: gau...@tc...
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

[Wrapper-user] Launched daemon on Mac OSX appears in Dock and in Menu Bar

[brian m. <br...@gi...>]

I am using wrapper-32-3.5.7.jar and am successfully launching my daemon on
Mac OS X Snow Leopard, however when running, an icon for the daemon appears
on the dock and also appears on the menu bar, complete with a 'Quit' menu
item.  How can I avoid this?

Thanks,

Brian McGann

[Wrapper-user] Java Service Wrapper 3.5.8

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

Hi all,
I would like to announce the release of 3.5.8 of the Java Service
Wrapper.  This version is primarily a bug fix release, but also includes
some new features:

*) A new option to use a dedicated thread to process all output from the JVM.

*) A new option to use pipe rather than a socket for backend
communication between the Wrapper and JVM.

*) It is now possible to use the Wrapper and its configuration as a
simple launcher for a standalone JVM without any monitoring.

*) The Wrapper will now automatically configure an account specified
to run the Wrapper as a service if it did not already have permission
to do so.

There were also some important fixes:

*) Starting with 3.5.7, we started signing our Windows binaries.
This was a much requested improvement which will help with security.
Overall it worked great, but we had some checks in our own code to log
messages if there were any problems with the signature.  On properly
configured systems everything was working great.   But we were being
overly strict and shutting down if there were any problems.
Some Windows 2008 users had configured their systems in such a way
that the Comodo root certificate that we use was not being authorized.
 Even though the OS was allowing the Wrapper to be launched, we were
shutting ourselves down.
The Wrapper will now only shut itself down if we detect that the
Wrapper binary is actually corrupted.   In other cases, we assume that
if the OS allowed us to be launched then it is OK to run.
This issue could cause problems for applications which distributed
their applications with 3.5.7 if they are run on such systems.

*) Improved the way the Java side of the Wrapper detects when the
Wrapper has failed. The Wrapper had always contained code which would
shut the JVM down automatically whenever it lost contact with the
Wrapper process for more than the ping timeout.  This was there to
prevent the JVM from becoming a zombie process in the event that the
Wrapper process were to crash.   On Windows it is not possible to kill
processes running in the service environment and would require a
system restart to recover.
The problem was that on very heavily IO loaded systems, the Wrapper
could sometimes get stuck blocking to write log output to disk.  If
this happened for long enough then the JVM would time out and exit.
The Wrapper would recover by restarting the JVM, but still this was
not desirable.
Starting with 3.5.8, The Java side of the Wrapper will now never shut
itself down in cases like this.   It uses a different mechanism which
actually confirms that the Wrapper process is gone before shutting
down so it will still never become a zombie.

Please see the release notes for a full list of changes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html#3.5.8

The full release is available on the Wrapper site:
http://wrapper.tanukisoftware.com/doc/english/download.jsp

As always, please let us know how we can continue to improve the
Wrapper to meet your needs.

Sincerely,
Leif Mortenson
Tanuki Software, Ltd.
http://www.tanukisoftware.com

[Wrapper-user] Can't start more than 50 windows services

[Efrain P. <efr...@ze...>]

Hi

I'm testing the community edition.
Everything was working OK until I've reached 50 services installed on a 
Windows Machine.
After the 50 service is running, I'm unable to start any new service 
using the wrapper.
Is this a limitation of the community edition?

--------------------------------------------------------------------------------------------------
Java Service Wrapper Community Edition 32-bit 3.5.7
   Copyright (C) 1999-2010 Tanuki Software, Ltd. All Rights Reserved.
http://wrapper.tanukisoftware.com
--------------------------------------------------------------------------------------------------
Microsoft Windows Server 2003 R2
Standard x64 Edition
Service Pack 2
--------------------------------------------------------------------------------------------------

Best Regards!

Re: [Wrapper-user] "unable to bind listener" Error

[Christian M. <chr...@ta...>]

HI Uri,

I'm sorry for the trouble.

The error you are seeing when trying to bind on port 32000 is actually not a
typical  error.

Usually when the bind fails due to the port being already in use, the return
code value of bind() is WSAEADDRINUSE [1]...
When this happens, the Wrapper will try the next port in the range until it
could successfully bind the port or all ports in the range are in use.
However in your case the bind returns quite a different error: WSAEACCES
So the Wrapper will stop trying to bind any port and exit the loop.

I was investigating this problem and it appears that the application which
was taking port 32000 on your PC actually bound the port with the
SO_EXCLUSIVEADDRUSE flag being set.
So while that program is running any other attempt to bind a port at this
port yields the WSAEACCES error instead of the WSAEADDRINUSE...

I will update the error handling of the Wrapper at that part. However
currently all versions of the Wrapper would stop with their loop after
encountering such bound port. Therefore the only workaround is to adjust the
port range (as you already figured out) when the error indicates
WSAEACCES...

Best Regards,
Christian

[1] http://support.microsoft.com/kb/819124

On Tue, Apr 26, 2011 at 6:27 PM, Uri Scheiner <ur...@no...> wrote:

> Hi,
>
> I encounter the following problem on Windows 2008:
>
> When trying to launch the service I get this message:
>
> STATUS | wrapper  | 2011/04/23 11:45:51.081 | --> Wrapper Started as
> Service
> FATAL  | wrapperp | 2011/04/23 11:45:51.190 | unable to bind listener to
> any port in the range 32000-32999. (An attempt was made to access a socket
> in a way forbidden by its access permissions. (0x271d))
> STATUS | wrapper  | 2011/04/23 11:45:51.299 | <-- Wrapper Stopped
>
> After doing some investigation it appears that only port 32000 is taken
> (and the rest of the ports are free). However, the wrapper does not scan and
> looking for other ports. I added the following line to the wrapper.conf:
>
> wrapper.jvm.port.min=32001
>
> and everything has been resolved.
> I was wondering whether it is a bug in the wrapper as I was expecting it to
> find port 32001 by itself.
>
> Uri
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] "unable to bind listener" Error

[Uri S. <ur...@no...>]

Hi,

I encounter the following problem on Windows 2008:

When trying to launch the service I get this message:

STATUS | wrapper  | 2011/04/23 11:45:51.081 | --> Wrapper Started as
Service
FATAL  | wrapperp | 2011/04/23 11:45:51.190 | unable to bind listener to
any port in the range 32000-32999. (An attempt was made to access a socket
in a way forbidden by its access permissions. (0x271d))
STATUS | wrapper  | 2011/04/23 11:45:51.299 | <-- Wrapper Stopped

After doing some investigation it appears that only port 32000 is taken (and
the rest of the ports are free). However, the wrapper does not scan and
looking for other ports. I added the following line to the wrapper.conf:

wrapper.jvm.port.min=32001

and everything has been resolved.
I was wondering whether it is a bug in the wrapper as I was expecting it to
find port 32001 by itself.

Uri

Re: [Wrapper-user] Boot classpath with spaces

[Christian M. <chr...@ta...>]

Martin,

I'm sorry for the delay on this.

The problem is that on Windows the command line of the JVM is
literally a line, while in Unix it's an array. So in windows each
element which has spaces but sticks together needs to be quoted. unix
doesn't need that and actually takes the quotes as part of the
parameter.

please try the following setting:
wrapper.java.additional.1="-Xbootclasspath/p:C:\wrapper sample\sample.jar"
wrapper.java.additional.1.stripquotes=true

This way, the Wrapper will strip of the quotes for the command line on
unix, but be able to preserve it on Windows.

Hope this helps you out.
Best Regards,
Christian

On Mon, Apr 4, 2011 at 4:31 PM, Martin Keller
<mar...@un...> wrote:
> Hello,
>
> we have a little problem when specifying the boot class in
> wrapper.conf-Files.
> If the path contains spaces, the Windows version needs a quoted
> specification, e.g.
>
> wrapper.java.additional.1="-Xbootclasspath/p:C:\wrapper sample\sample.jar"
>
> while the Unix doesn't accept quotes at all.
> Is there any consistent way of specifying the boot classpath?
>
>
> Sincerely,
> Martin
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>