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

Re: [Wrapper-user] NT Service log on as

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

Prasad Keskar wrote:

>My OS is XP professional. Although proper rights to the administrator user maybe an issue, I was more concerned with automating this process of logging in as administrator. When I run/install my app using the wrapper the "log on as" is Local System. How can I make it to administrator? The way you have explained to do this is a manual way of doing it. Can the administrator "log on as" not be the default by setting some property for the wrapper? Is there any setting in the conf file which will always run/install the service (using wrapper) with the "log on as" set to administrator?
>
There is currently no way of doing this from the conf file.  Could you 
please post a feature request on this and I'll look into getting it 
implemented?  That way you will be notified when the feature request is 
implemented :-)

Thanks,
Leif

RE: [Wrapper-user] NT Service log on as

[Prasad K. <pra...@em...>]

Hi Leif

First of all thank you for a prompt reply.

My OS is XP professional. Although proper rights to the administrator =
user maybe an issue, I was more concerned with automating this process =
of logging in as administrator. When I run/install my app using the =
wrapper the "log on as" is Local System. How can I make it to =
administrator? The way you have explained to do this is a manual way of =
doing it. Can the administrator "log on as" not be the default by =
setting some property for the wrapper? Is there any setting in the conf =
file which will always run/install the service (using wrapper) with the =
"log on as" set to administrator?

Regards,
Prasad


-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]
Sent: Monday, December 02, 2002 10:03 PM
To: wra...@li...
Subject: Re: [Wrapper-user] NT Service log on as


Prasad,
    Currently, the Wrapper does not do anything special to  run the=20
Wrapper/Java
processes as a specific user.  If you go into the service manager and =
select
Properties for the Service, then you will see a login tab where you can=20
specify
the user name and password to use when running the service.

    I tried this on my WinXP box here and work and keep getting the=20
following though:
---
System error 1069 has occurred.

The service did not start due to a logon failure.
---

    From the following site, it looks like you have to enable the "Logon =

as Service" right
for the user to be logged in as a service.  That is done using the Group =

Policy Editor.
I'll have to give that a try at home as gpedit.msc does not appear to be =

included with
the Home edition of XP. (The notebook I bought for work only came with=20
XP home :-/)
http://www.sbss.com.au/products/netfaq.htm#W2KService

    What OS are you using.  From what I can see so far you can only do=20
this with
Professional versions Windows??

Cheers,
Leif

Prasad Keskar wrote:

>I had a question about the "log on as" for the Java service wrapper. =
Whenever I run my app as a service using java service wrapper, it always =
uses "Local System" as the log on type. How to change this? I mean I =
want my app to run as a service with the administrator as the user (log =
on as should be administrator). I know I will need to supply the =
administrator user name & password to the service somehow for this =
requirement. Can someone help me with this? I will really appreciate any =
help.
> =20
>




-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T=20
handheld. Power & Color in a compact size!=20
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] NT Service log on as

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

Prasad,
    Currently, the Wrapper does not do anything special to  run the 
Wrapper/Java
processes as a specific user.  If you go into the service manager and select
Properties for the Service, then you will see a login tab where you can 
specify
the user name and password to use when running the service.

    I tried this on my WinXP box here and work and keep getting the 
following though:
---
System error 1069 has occurred.

The service did not start due to a logon failure.
---

    From the following site, it looks like you have to enable the "Logon 
as Service" right
for the user to be logged in as a service.  That is done using the Group 
Policy Editor.
I'll have to give that a try at home as gpedit.msc does not appear to be 
included with
the Home edition of XP. (The notebook I bought for work only came with 
XP home :-/)
http://www.sbss.com.au/products/netfaq.htm#W2KService

    What OS are you using.  From what I can see so far you can only do 
this with
Professional versions Windows??

Cheers,
Leif

Prasad Keskar wrote:

>I had a question about the "log on as" for the Java service wrapper. Whenever I run my app as a service using java service wrapper, it always uses "Local System" as the log on type. How to change this? I mean I want my app to run as a service with the administrator as the user (log on as should be administrator). I know I will need to supply the administrator user name & password to the service somehow for this requirement. Can someone help me with this? I will really appreciate any help.
>  
>

[Wrapper-user] NT Service log on as

[Prasad K. <pra...@em...>]

Hi all

I had a question about the "log on as" for the Java service wrapper. =
Whenever I run my app as a service using java service wrapper, it always =
uses "Local System" as the log on type. How to change this? I mean I =
want my app to run as a service with the administrator as the user (log =
on as should be administrator). I know I will need to supply the =
administrator user name & password to the service somehow for this =
requirement. Can someone help me with this? I will really appreciate any =
help.

Regards,
Prasad

Re: [Wrapper-user] environment variables

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

Todd Enright wrote:

>I will will definitely be exercising the wrapper in a full QA environment
>and writing several apps using it, so I am sure to have more feedback in the
>future for you.
>
I'll brace myself....

Re: [Wrapper-user] environment variables

[Todd E. <ten...@te...>]

Yeah, my app is not setting it to that at all.  My only guess is that since
the %os% variable says "windows_nt" on xp, that either the system or some
java lib is returning c:\winnt by defualt for windir.  Obviously that is a
huge shot in the dark, but windows, actually any os, can be weird.

I will will definitely be exercising the wrapper in a full QA environment
and writing several apps using it, so I am sure to have more feedback in the
future for you.


----- Original Message -----
From: "Leif Mortenson" <le...@ta...>
To: <wra...@li...>
Sent: Wednesday, November 27, 2002 11:51 PM
Subject: Re: [Wrapper-user] environment variables


> Todd Enright wrote:
>
> > Hi Leif,
> > I needed to pass the parameters to the wrapper.java.additional
> > section, as they are called from system.getProperty().  Things are up
> > and working properly now!  Thank you for the assistance.  This wrapper
> > is excellent, and very flexible.  By far the best out there!
>
> Thanks.  Glad you got it working.
>
> If you don't set the windir property manually is it defaulting to
> C:\WinNT?  Or is that something that your application is doing.  Ie
> using that default if the property is not set?  It The JVM is defaulting
> to C:\WinNT, that sounds like a Java bug or something.
>
> Leif
>
> >
> > Cheers,
> > Todd
> >
> >     ----- Original Message -----
> >     From: Leif Mortenson <mailto:le...@ta...>
> >     To: wra...@li...
> >     <mailto:wra...@li...>
> >     Sent: Wednesday, November 27, 2002 8:06 PM
> >     Subject: Re: [Wrapper-user] environment variables
> >
> >     Todd Enright wrote:
> >
> >>     Hey Leif,
> >>     Sorry.... totally forgot some good information.  I am passing in
> >>     windir as an argument, then returning the value to web server
> >>     scripts through a cgi.  I don't think I'm getting the argument
> >>     passed properly.  Here is what I have in my wrapper.conf for
> >>     application parameters.
> >>
> >>     wrapper.app.parameter.1=P2PShell
> >>     wrapper.app.parameter.3=-DasService=yes
> >>     wrapper.app.parameter.4=-Dwindir=%windir%
> >
> >     This looks ok but because you are using -D...  I have to ask.   Do
> >     you intend to be passing these parameters to the main method of
> >     P2PShell.class? Or do you mean to be setting them as properties
> >     that you get from System.getProperty(...)?  If it is the later,
> >     then you will need to move them to the wrapper.java.additional
> >     section.  This will pass the parameters to the JVM rather than to
> >     the class's main method as you are doing now.
> >
> >     wrapper.java.additional.1=-DasService=yes
> >     wrapper.java.additional.2=-Dwindir=%windir%
> >
> >>     I told java to return verbose information, and although it breaks
> >>     the command, it shows the construction of the command.  Here's
> >>     what it shows.  Can you tell me if the construction of the
> >>     command looks good (other than the -v which breaks things)
> >
> >     You can do this by enabling debug output to the console using the
> >     following:
> >     wrapper.console.loglevel=DEBUG
> >
> >>      wrapper  | --> Wrapper Started as Console
> >>     wrapper  | Launching a JVM...
> >>     wrapper  | can not execute ""C:\WINDOWS\java.exe -v" -Xms16m
> >>     -Xmx128m -Djava.lib
> >>     rary.path="./lib" -classpath
> >>     "./lib/wrapper.jar;./lib/wrappertest.jar;C:\Program
> >>      Files\ClearCube Management Suite\DataFailover\.;C:\Program
> >>     Files\ClearCube Mana
> >>     gement Suite\DataFailover\jaxp1.0.1\parser.jar;C:\Program
> >>     Files\ClearCube Manage
> >>     ment Suite\DataFailover\jaxp1.0.1\jaxp.jar;C:\Program
> >>     Files\ClearCube Management
> >>      Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar;C:\Program
> >>     Files\ClearCube Manage
> >>     ment Suite\DataFailover\soap.jar;C:\Program Files\ClearCube
> >>     Management Suite\Dat
> >>     aFailover;C:\Program Files\ClearCube Management
> >>     Suite\DataFailover\xerces.jar;C:
> >>     \Program Files\ClearCube Management Suite\DataFailover\xalan.jar"
> >>     -Dwrapper.key=
> >>     "nsYL7tEdn_k1zaW1" -Dwrapper.port=1777 -Dwrapper.debug="TRUE"
> >>     -Dwrapper.cpu.time
> >>     out="10" -Dwrapper.jvmid=1 com.silveregg.wrapper.WrapperSimpleApp
> >>     P2PShell -Dshu
> >>     tdown.method=stopApplication -Dwindir=C:\WINDOWS" (ERR=2)
> >>     wrapper  | Critical error: wait for JVM process failed
> >
> >
> >     Other than the comment above, this all looks ok.  The only thing
> >     is that you most likely do not need to be including the
> >     wrapertest.jar file in your classpath.
> >
> >     Cheers,
> >     Leif
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] environment variables

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

Todd Enright wrote:

> Hi Leif,
> I needed to pass the parameters to the wrapper.java.additional 
> section, as they are called from system.getProperty().  Things are up 
> and working properly now!  Thank you for the assistance.  This wrapper 
> is excellent, and very flexible.  By far the best out there!

Thanks.  Glad you got it working.

If you don't set the windir property manually is it defaulting to 
C:\WinNT?  Or is that something that your application is doing.  Ie 
using that default if the property is not set?  It The JVM is defaulting 
to C:\WinNT, that sounds like a Java bug or something.

Leif

>  
> Cheers,
> Todd
>
>     ----- Original Message -----
>     From: Leif Mortenson <mailto:le...@ta...>
>     To: wra...@li...
>     <mailto:wra...@li...>
>     Sent: Wednesday, November 27, 2002 8:06 PM
>     Subject: Re: [Wrapper-user] environment variables
>
>     Todd Enright wrote:
>
>>     Hey Leif,
>>     Sorry.... totally forgot some good information.  I am passing in
>>     windir as an argument, then returning the value to web server
>>     scripts through a cgi.  I don't think I'm getting the argument
>>     passed properly.  Here is what I have in my wrapper.conf for
>>     application parameters.
>>      
>>     wrapper.app.parameter.1=P2PShell
>>     wrapper.app.parameter.3=-DasService=yes
>>     wrapper.app.parameter.4=-Dwindir=%windir%
>
>     This looks ok but because you are using -D...  I have to ask.   Do
>     you intend to be passing these parameters to the main method of
>     P2PShell.class? Or do you mean to be setting them as properties
>     that you get from System.getProperty(...)?  If it is the later,
>     then you will need to move them to the wrapper.java.additional
>     section.  This will pass the parameters to the JVM rather than to
>     the class's main method as you are doing now.
>
>     wrapper.java.additional.1=-DasService=yes
>     wrapper.java.additional.2=-Dwindir=%windir%
>
>>     I told java to return verbose information, and although it breaks
>>     the command, it shows the construction of the command.  Here's
>>     what it shows.  Can you tell me if the construction of the
>>     command looks good (other than the -v which breaks things)
>
>     You can do this by enabling debug output to the console using the
>     following:
>     wrapper.console.loglevel=DEBUG
>
>>      wrapper  | --> Wrapper Started as Console
>>     wrapper  | Launching a JVM...
>>     wrapper  | can not execute ""C:\WINDOWS\java.exe -v" -Xms16m
>>     -Xmx128m -Djava.lib
>>     rary.path="./lib" -classpath
>>     "./lib/wrapper.jar;./lib/wrappertest.jar;C:\Program
>>      Files\ClearCube Management Suite\DataFailover\.;C:\Program
>>     Files\ClearCube Mana
>>     gement Suite\DataFailover\jaxp1.0.1\parser.jar;C:\Program
>>     Files\ClearCube Manage
>>     ment Suite\DataFailover\jaxp1.0.1\jaxp.jar;C:\Program
>>     Files\ClearCube Management
>>      Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar;C:\Program
>>     Files\ClearCube Manage
>>     ment Suite\DataFailover\soap.jar;C:\Program Files\ClearCube
>>     Management Suite\Dat
>>     aFailover;C:\Program Files\ClearCube Management
>>     Suite\DataFailover\xerces.jar;C:
>>     \Program Files\ClearCube Management Suite\DataFailover\xalan.jar"
>>     -Dwrapper.key=
>>     "nsYL7tEdn_k1zaW1" -Dwrapper.port=1777 -Dwrapper.debug="TRUE"
>>     -Dwrapper.cpu.time
>>     out="10" -Dwrapper.jvmid=1 com.silveregg.wrapper.WrapperSimpleApp
>>     P2PShell -Dshu
>>     tdown.method=stopApplication -Dwindir=C:\WINDOWS" (ERR=2)
>>     wrapper  | Critical error: wait for JVM process failed
>
>
>     Other than the comment above, this all looks ok.  The only thing
>     is that you most likely do not need to be including the
>     wrapertest.jar file in your classpath.
>
>     Cheers,
>     Leif
>

Re: [Wrapper-user] environment variables

[Todd E. <ten...@te...>]

Hi Leif,
I needed to pass the parameters to the wrapper.java.additional section, =
as they are called from system.getProperty().  Things are up and working =
properly now!  Thank you for the assistance.  This wrapper is excellent, =
and very flexible.  By far the best out there!

Cheers,
Todd
  ----- Original Message -----=20
  From: Leif Mortenson=20
  To: wra...@li...=20
  Sent: Wednesday, November 27, 2002 8:06 PM
  Subject: Re: [Wrapper-user] environment variables


  Todd Enright wrote:

    Hey Leif,
    Sorry.... totally forgot some good information.  I am passing in =
windir as an argument, then returning the value to web server scripts =
through a cgi.  I don't think I'm getting the argument passed properly.  =
Here is what I have in my wrapper.conf for application parameters.

    wrapper.app.parameter.1=3DP2PShell
    wrapper.app.parameter.3=3D-DasService=3Dyes=20
    wrapper.app.parameter.4=3D-Dwindir=3D%windir%
  This looks ok but because you are using -D...  I have to ask.   Do you =
intend to be passing these parameters to the main method of =
P2PShell.class? Or do you mean to be setting them as properties that you =
get from System.getProperty(...)?  If it is the later, then you will =
need to move them to the wrapper.java.additional section.  This will =
pass the parameters to the JVM rather than to the class's main method as =
you are doing now.

  wrapper.java.additional.1=3D-DasService=3Dyes
  wrapper.java.additional.2=3D-Dwindir=3D%windir%


    I told java to return verbose information, and although it breaks =
the command, it shows the construction of the command.  Here's what it =
shows.  Can you tell me if the construction of the command looks good =
(other than the -v which breaks things)
  You can do this by enabling debug output to the console using the =
following:
  wrapper.console.loglevel=3DDEBUG

     wrapper  | --> Wrapper Started as Console

    wrapper  | Launching a JVM...
    wrapper  | can not execute ""C:\WINDOWS\java.exe -v" -Xms16m =
-Xmx128m -Djava.lib
    rary.path=3D"./lib" -classpath =
"./lib/wrapper.jar;./lib/wrappertest.jar;C:\Program
     Files\ClearCube Management Suite\DataFailover\.;C:\Program =
Files\ClearCube Mana
    gement Suite\DataFailover\jaxp1.0.1\parser.jar;C:\Program =
Files\ClearCube Manage
    ment Suite\DataFailover\jaxp1.0.1\jaxp.jar;C:\Program =
Files\ClearCube Management
     Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar;C:\Program =
Files\ClearCube Manage
    ment Suite\DataFailover\soap.jar;C:\Program Files\ClearCube =
Management Suite\Dat
    aFailover;C:\Program Files\ClearCube Management =
Suite\DataFailover\xerces.jar;C:
    \Program Files\ClearCube Management Suite\DataFailover\xalan.jar" =
-Dwrapper.key=3D
    "nsYL7tEdn_k1zaW1" -Dwrapper.port=3D1777 -Dwrapper.debug=3D"TRUE" =
-Dwrapper.cpu.time
    out=3D"10" -Dwrapper.jvmid=3D1 =
com.silveregg.wrapper.WrapperSimpleApp P2PShell -Dshu
    tdown.method=3DstopApplication -Dwindir=3DC:\WINDOWS" (ERR=3D2)
    wrapper  | Critical error: wait for JVM process failed

  Other than the comment above, this all looks ok.  The only thing is =
that you most likely do not need to be including the wrapertest.jar file =
in your classpath.

  Cheers,
  Leif

Re: [Wrapper-user] environment variables

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

Todd,
    I don't understand.  In this output %windir% appears to be correctly 
resolving to C:\Windows
Are you still experiencing the problem?

    Where are you seeing that windir=C:\WinNT?  Are you testing the 
value inside of Java?  If so, it may
have something to do with the the other reply I sent you where the java 
properties were being passed
to the main class rather than to the jvm.

    Can you recheck this and let me know.

    Thanks,
    Leif

Todd Enright wrote:

> You betcha.  Here's what I get. 
>  
>
>     ----- Original Message -----
>     From: Leif Mortenson <mailto:le...@ta...>
>     To: wra...@li...
>     <mailto:wra...@li...>
>     Sent: Wednesday, November 27, 2002 10:53 AM
>     Subject: Re: [Wrapper-user] environment variables
>
>     I just put a debug build of Wrapper.exe up on the server at
>     http://wrapper.sourceforge.net/Wrapper.exe
>     Can you BACKUP your current wrapper.exe and try it with this one?
>     It will dump out a bunch of debug info as it reads in the
>     properties from the file.
>     Could you post what you get?
>
>     Thanks,
>     Leif
>
>     Todd Enright wrote:
>
>>     Hi Leif,
>>     The variable is set to c:\windows in the control panel, and this
>>     is verified by going to a command prompt and typing SET.  I also
>>     have windir=c:\windows in the system variables but no setting in
>>     the user section.
>>      
>>     I have get the same results by running wrapper as either a
>>     console app, or a service.
>>      
>>     I'll keep digging on my end. 
>>
>>     Thanks,
>>     Todd
>>
>>         ----- Original Message -----
>>         From: Leif Mortenson <mailto:le...@ta...>
>>         To: wra...@li...
>>         <mailto:wra...@li...>
>>         Sent: Wednesday, November 27, 2002 10:22 AM
>>         Subject: Re: [Wrapper-user] environment variables
>>
>>         Todd,
>>             Strange, All the wrapper does is call the standard
>>         Windows API to get the
>>         system environment variable's value.
>>
>>             I just tested this on a Windows XP machine and on my
>>         machine I got the correct
>>         value:  C:\WINDOWS
>>
>>             What do you get if you open a command prompt and type SET
>>         at the prompt?
>>
>>             Do you see this problem when run as both a service and as
>>         a console app?  Or
>>         just one or the other?
>>
>>             You might want to go in and look at the environment
>>         variable setting in the
>>         system control panel.  There are two sections.  User
>>         variables and system
>>         variables.  I have windir=c:\windows in the system variables
>>         but no setting in the
>>         user section.  If the variable is set in both places, then
>>         you may be getting
>>         different values depending on context.
>>
>>             Let me know whether or not any of this helps.
>>
>>             Cheers,
>>             Leif
>>
>>
>>         Todd Enright wrote:
>>
>>>         I am using ver 2.2.9 on XP. 
>>>         The environment variable for WINDIR returning c:\winnt, but
>>>         the actuall WINDIR variable on my machine is c:\windows, and
>>>         further i don't have any c:\winnt directory on my machine. 
>>>          
>>>         Do you know why this is happening?
>>
>>
>

Re: [Wrapper-user] environment variables

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

Todd Enright wrote:

> Hey Leif,
> Sorry.... totally forgot some good information.  I am passing in 
> windir as an argument, then returning the value to web server scripts 
> through a cgi.  I don't think I'm getting the argument passed 
> properly.  Here is what I have in my wrapper.conf for application 
> parameters.
>  
> wrapper.app.parameter.1=P2PShell
> wrapper.app.parameter.3=-DasService=yes
> wrapper.app.parameter.4=-Dwindir=%windir%

This looks ok but because you are using -D...  I have to ask.   Do you 
intend to be passing these parameters to the main method of 
P2PShell.class? Or do you mean to be setting them as properties that you 
get from System.getProperty(...)?  If it is the later, then you will 
need to move them to the wrapper.java.additional section.  This will 
pass the parameters to the JVM rather than to the class's main method as 
you are doing now.

wrapper.java.additional.1=-DasService=yes
wrapper.java.additional.2=-Dwindir=%windir%

> I told java to return verbose information, and although it breaks the 
> command, it shows the construction of the command.  Here's what it 
> shows.  Can you tell me if the construction of the command looks good 
> (other than the -v which breaks things)

You can do this by enabling debug output to the console using the following:
wrapper.console.loglevel=DEBUG

>  wrapper  | --> Wrapper Started as Console
> wrapper  | Launching a JVM...
> wrapper  | can not execute ""C:\WINDOWS\java.exe -v" -Xms16m -Xmx128m 
> -Djava.lib
> rary.path="./lib" -classpath 
> "./lib/wrapper.jar;./lib/wrappertest.jar;C:\Program
>  Files\ClearCube Management Suite\DataFailover\.;C:\Program 
> Files\ClearCube Mana
> gement Suite\DataFailover\jaxp1.0.1\parser.jar;C:\Program 
> Files\ClearCube Manage
> ment Suite\DataFailover\jaxp1.0.1\jaxp.jar;C:\Program Files\ClearCube 
> Management
>  Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar;C:\Program 
> Files\ClearCube Manage
> ment Suite\DataFailover\soap.jar;C:\Program Files\ClearCube Management 
> Suite\Dat
> aFailover;C:\Program Files\ClearCube Management 
> Suite\DataFailover\xerces.jar;C:
> \Program Files\ClearCube Management Suite\DataFailover\xalan.jar" 
> -Dwrapper.key=
> "nsYL7tEdn_k1zaW1" -Dwrapper.port=1777 -Dwrapper.debug="TRUE" 
> -Dwrapper.cpu.time
> out="10" -Dwrapper.jvmid=1 com.silveregg.wrapper.WrapperSimpleApp 
> P2PShell -Dshu
> tdown.method=stopApplication -Dwindir=C:\WINDOWS" (ERR=2)
> wrapper  | Critical error: wait for JVM process failed


Other than the comment above, this all looks ok.  The only thing is that 
you most likely do not need to be including the wrapertest.jar file in 
your classpath.

Cheers,
Leif

Re: [Wrapper-user] environment variables

[Todd E. <ten...@te...>]

I am putting the output in the body this time.

Getting the system path: C:\Python22\.;.;c:\unxutils;C:\Program =
Files\ClearCube Management Suite\DataFailover;C:\Program Files\ClearCube =
Management Suite\DataFailover\perl\bin;C:\Program Files\ClearCube =
Management Suite\DataFailover\perl\lib;;;.;C:\Program Files\ClearCube =
Management Suite\DataFailover;C:\Program Files\ClearCube Management =
Suite\DataFailover\perl\bin;C:\Program Files\ClearCube Management =
Suite\DataFailover\perl\lib;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\Sy=
stem32\Wbem;C:\PROGRA~1\ULTRAE~1;C:\Program Files\Resource Pro =
Kit\;c:\cygwin\bin;c:\program files\vide\;c:\jdk1.3.1_02\bin
PATH[0]=3DC:\Python22\.
PATH[1]=3D.
PATH[2]=3Dc:\unxutils
PATH[3]=3DC:\Program Files\ClearCube Management Suite\DataFailover
PATH[4]=3DC:\Program Files\ClearCube Management =
Suite\DataFailover\perl\bin
PATH[5]=3DC:\Program Files\ClearCube Management =
Suite\DataFailover\perl\lib
PATH[6]=3D
PATH[7]=3D
PATH[8]=3D.
PATH[9]=3DC:\Program Files\ClearCube Management Suite\DataFailover
PATH[10]=3DC:\Program Files\ClearCube Management =
Suite\DataFailover\perl\bin
PATH[11]=3DC:\Program Files\ClearCube Management =
Suite\DataFailover\perl\lib
PATH[12]=3D
PATH[13]=3DC:\WINDOWS\system32
PATH[14]=3DC:\WINDOWS
PATH[15]=3DC:\WINDOWS\System32\Wbem
PATH[16]=3DC:\PROGRA~1\ULTRAE~1
PATH[17]=3DC:\Program Files\Resource Pro Kit\
PATH[18]=3Dc:\cygwin\bin
PATH[19]=3Dc:\program files\vide\
PATH[20]=3Dc:\jdk1.3.1_02\bin
PATH[1245032]=3D<null>
evaluateEnvironmentVariables('%SystemRoot%\java.exe', buffer)
  in=3D'%SystemRoot%\java.exe', out=3D''
  in=3D'\java.exe', out=3D''
  final buffer=3D'C:\WINDOWS\java.exe'
evaluateEnvironmentVariables('com.silveregg.wrapper.WrapperSimpleApp', =
buffer)
  in=3D'com.silveregg.wrapper.WrapperSimpleApp', out=3D''
  final buffer=3D'com.silveregg.wrapper.WrapperSimpleApp'
evaluateEnvironmentVariables('P2PShell', buffer)
  in=3D'P2PShell', out=3D''
  final buffer=3D'P2PShell'
evaluateEnvironmentVariables('-DasService=3Dyes ', buffer)
  in=3D'-DasService=3Dyes ', out=3D''
  final buffer=3D'-DasService=3Dyes '
evaluateEnvironmentVariables('-Dwindir=3D%windir%', buffer)
  in=3D'-Dwindir=3D%windir%', out=3D''
  final buffer=3D'-Dwindir=3DC:\WINDOWS'
evaluateEnvironmentVariables('./lib/wrapper.jar', buffer)
  in=3D'./lib/wrapper.jar', out=3D''
  final buffer=3D'./lib/wrapper.jar'
evaluateEnvironmentVariables('./lib/wrappertest.jar', buffer)
  in=3D'./lib/wrappertest.jar', out=3D''
  final buffer=3D'./lib/wrappertest.jar'
evaluateEnvironmentVariables('%cc_install_dir%\.', buffer)
  in=3D'%cc_install_dir%\.', out=3D''
  in=3D'\.', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\.'
evaluateEnvironmentVariables('%cc_install_dir%\jaxp1.0.1\parser.jar', =
buffer)
  in=3D'%cc_install_dir%\jaxp1.0.1\parser.jar', out=3D''
  in=3D'\jaxp1.0.1\parser.jar', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\jaxp1.0.1\parser.jar'
evaluateEnvironmentVariables('%cc_install_dir%\jaxp1.0.1\jaxp.jar', =
buffer)
  in=3D'%cc_install_dir%\jaxp1.0.1\jaxp.jar', out=3D''
  in=3D'\jaxp1.0.1\jaxp.jar', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\jaxp1.0.1\jaxp.jar'
evaluateEnvironmentVariables('%cc_install_dir%\lf\oyoahalnf\oyoahalnf.jar=
', buffer)
  in=3D'%cc_install_dir%\lf\oyoahalnf\oyoahalnf.jar', out=3D''
  in=3D'\lf\oyoahalnf\oyoahalnf.jar', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar'
evaluateEnvironmentVariables('%cc_install_dir%\soap.jar', buffer)
  in=3D'%cc_install_dir%\soap.jar', out=3D''
  in=3D'\soap.jar', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\soap.jar'
evaluateEnvironmentVariables('%cc_install_dir%', buffer)
  in=3D'%cc_install_dir%', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover'
evaluateEnvironmentVariables('%cc_install_dir%\xerces.jar', buffer)
  in=3D'%cc_install_dir%\xerces.jar', out=3D''
  in=3D'\xerces.jar', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\xerces.jar'
evaluateEnvironmentVariables('%cc_install_dir%\xalan.jar', buffer)
  in=3D'%cc_install_dir%\xalan.jar', out=3D''
  in=3D'\xalan.jar', out=3D''
  final buffer=3D'C:\Program Files\ClearCube Management =
Suite\DataFailover\xalan.jar'
evaluateEnvironmentVariables('./lib', buffer)
  in=3D'./lib', out=3D''
  final buffer=3D'./lib'
evaluateEnvironmentVariables('16', buffer)
  in=3D'16', out=3D''
  final buffer=3D'16'
evaluateEnvironmentVariables('128', buffer)
  in=3D'128', out=3D''
  final buffer=3D'128'
evaluateEnvironmentVariables('1777', buffer)
  in=3D'1777', out=3D''
  final buffer=3D'1777'
evaluateEnvironmentVariables('10', buffer)
  in=3D'10', out=3D''
  final buffer=3D'10'
evaluateEnvironmentVariables('PM', buffer)
  in=3D'PM', out=3D''
  final buffer=3D'PM'
evaluateEnvironmentVariables('INFO', buffer)
  in=3D'INFO', out=3D''
  final buffer=3D'INFO'
evaluateEnvironmentVariables('../logs/wrapper.log', buffer)
  in=3D'../logs/wrapper.log', out=3D''
  final buffer=3D'../logs/wrapper.log'
evaluateEnvironmentVariables('LPTM', buffer)
  in=3D'LPTM', out=3D''
  final buffer=3D'LPTM'
evaluateEnvironmentVariables('DEBUG', buffer)
  in=3D'DEBUG', out=3D''
  final buffer=3D'DEBUG'
evaluateEnvironmentVariables('0', buffer)
  in=3D'0', out=3D''
  final buffer=3D'0'
evaluateEnvironmentVariables('0', buffer)
  in=3D'0', out=3D''
  final buffer=3D'0'
evaluateEnvironmentVariables('NONE', buffer)
  in=3D'NONE', out=3D''
  final buffer=3D'NONE'
evaluateEnvironmentVariables('/var/run/testwrapper.pid', buffer)
  in=3D'/var/run/testwrapper.pid', out=3D''
  final buffer=3D'/var/run/testwrapper.pid'
evaluateEnvironmentVariables('CC DCI(test)', buffer)
  in=3D'CC DCI(test)', out=3D''
  final buffer=3D'CC DCI(test)'
evaluateEnvironmentVariables('Clearcube DCF', buffer)
  in=3D'Clearcube DCF', out=3D''
  final buffer=3D'Clearcube DCF'
evaluateEnvironmentVariables('Clearcube Distributed Computing =
Framework', buffer)
  in=3D'Clearcube Distributed Computing Framework', out=3D''
  final buffer=3D'Clearcube Distributed Computing Framework'
evaluateEnvironmentVariables('', buffer)
  final buffer=3D''
evaluateEnvironmentVariables('AUTO_START', buffer)
  in=3D'AUTO_START', out=3D''
  final buffer=3D'AUTO_START'
evaluateEnvironmentVariables('NORMAL', buffer)
  in=3D'NORMAL', out=3D''
  final buffer=3D'NORMAL'
Debug Config Properties:
    name:wrapper.app.parameter.1 value:P2PShell
    name:wrapper.app.parameter.3 value:-DasService=3Dyes=20
    name:wrapper.app.parameter.4 value:-Dwindir=3DC:\WINDOWS
    name:wrapper.console.format value:PM
    name:wrapper.console.loglevel value:INFO
    name:wrapper.java.classpath.1 value:./lib/wrapper.jar
    name:wrapper.java.classpath.10 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\xalan.jar
    name:wrapper.java.classpath.2 value:./lib/wrappertest.jar
    name:wrapper.java.classpath.3 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\.
    name:wrapper.java.classpath.4 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\jaxp1.0.1\parser.jar
    name:wrapper.java.classpath.5 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\jaxp1.0.1\jaxp.jar
    name:wrapper.java.classpath.6 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar
    name:wrapper.java.classpath.7 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\soap.jar
    name:wrapper.java.classpath.8 value:C:\Program Files\ClearCube =
Management Suite\DataFailover
    name:wrapper.java.classpath.9 value:C:\Program Files\ClearCube =
Management Suite\DataFailover\xerces.jar
    name:wrapper.java.command value:C:\WINDOWS\java.exe
    name:wrapper.java.initmemory value:16
    name:wrapper.java.library.path.1 value:./lib
    name:wrapper.java.mainclass =
value:com.silveregg.wrapper.WrapperSimpleApp
    name:wrapper.java.maxmemory value:128
    name:wrapper.logfile value:../logs/wrapper.log
    name:wrapper.logfile.format value:LPTM
    name:wrapper.logfile.loglevel value:DEBUG
    name:wrapper.logfile.maxfiles value:0
    name:wrapper.logfile.maxsize value:0
    name:wrapper.ntservice.dependency.1 value:
    name:wrapper.ntservice.description value:Clearcube Distributed =
Computing Framework
    name:wrapper.ntservice.displayname value:Clearcube DCF
    name:wrapper.ntservice.name value:CC DCI(test)
    name:wrapper.ntservice.process_priority value:NORMAL
    name:wrapper.ntservice.starttype value:AUTO_START
    name:wrapper.pidfile value:/var/run/testwrapper.pid
    name:wrapper.ping.timeout value:10
    name:wrapper.port value:1777
    name:wrapper.syslog.loglevel value:NONE

  ----- Original Message -----=20
  From: Leif Mortenson=20
  To: wra...@li...=20
  Sent: Wednesday, November 27, 2002 10:53 AM
  Subject: Re: [Wrapper-user] environment variables


  I just put a debug build of Wrapper.exe up on the server at
  http://wrapper.sourceforge.net/Wrapper.exe
  Can you BACKUP your current wrapper.exe and try it with this one?
  It will dump out a bunch of debug info as it reads in the properties =
from the file.
  Could you post what you get?

  Thanks,
  Leif

  Todd Enright wrote:

    Hi Leif,
    The variable is set to c:\windows in the control panel, and this is =
verified by going to a command prompt and typing SET.  I also have =
windir=3Dc:\windows in the system variables but no setting in the user =
section.

    I have get the same results by running wrapper as either a console =
app, or a service.

    I'll keep digging on my end. =20

    Thanks,
    Todd
      ----- Original Message -----=20
      From: Leif Mortenson=20
      To: wra...@li...=20
      Sent: Wednesday, November 27, 2002 10:22 AM
      Subject: Re: [Wrapper-user] environment variables


      Todd,
          Strange, All the wrapper does is call the standard Windows API =
to get the
      system environment variable's value.

          I just tested this on a Windows XP machine and on my machine I =
got the correct
      value:  C:\WINDOWS

          What do you get if you open a command prompt and type SET at =
the prompt?

          Do you see this problem when run as both a service and as a =
console app?  Or
      just one or the other?

          You might want to go in and look at the environment variable =
setting in the
      system control panel.  There are two sections.  User variables and =
system
      variables.  I have windir=3Dc:\windows in the system variables but =
no setting in the
      user section.  If the variable is set in both places, then you may =
be getting
      different values depending on context.

          Let me know whether or not any of this helps.

          Cheers,
          Leif


      Todd Enright wrote:

        I am using ver 2.2.9 on XP. =20
        The environment variable for WINDIR returning c:\winnt, but the =
actuall WINDIR variable on my machine is c:\windows, and further i don't =
have any c:\winnt directory on my machine. =20

        Do you know why this is happening?

Re: [Wrapper-user] environment variables

[Todd E. <ten...@te...>]

Hey Leif,
Sorry.... totally forgot some good information.  I am passing in windir =
as an argument, then returning the value to web server scripts through a =
cgi.  I don't think I'm getting the argument passed properly.  Here is =
what I have in my wrapper.conf for application parameters.

wrapper.app.parameter.1=3DP2PShell
wrapper.app.parameter.3=3D-DasService=3Dyes=20
wrapper.app.parameter.4=3D-Dwindir=3D%windir%

I told java to return verbose information, and although it breaks the =
command, it shows the construction of the command.  Here's what it =
shows.  Can you tell me if the construction of the command looks good =
(other than the -v which breaks things)

wrapper  | --> Wrapper Started as Console
wrapper  | Launching a JVM...
wrapper  | can not execute ""C:\WINDOWS\java.exe -v" -Xms16m -Xmx128m =
-Djava.lib
rary.path=3D"./lib" -classpath =
"./lib/wrapper.jar;./lib/wrappertest.jar;C:\Program
 Files\ClearCube Management Suite\DataFailover\.;C:\Program =
Files\ClearCube Mana
gement Suite\DataFailover\jaxp1.0.1\parser.jar;C:\Program =
Files\ClearCube Manage
ment Suite\DataFailover\jaxp1.0.1\jaxp.jar;C:\Program Files\ClearCube =
Management
 Suite\DataFailover\lf\oyoahalnf\oyoahalnf.jar;C:\Program =
Files\ClearCube Manage
ment Suite\DataFailover\soap.jar;C:\Program Files\ClearCube Management =
Suite\Dat
aFailover;C:\Program Files\ClearCube Management =
Suite\DataFailover\xerces.jar;C:
\Program Files\ClearCube Management Suite\DataFailover\xalan.jar" =
-Dwrapper.key=3D
"nsYL7tEdn_k1zaW1" -Dwrapper.port=3D1777 -Dwrapper.debug=3D"TRUE" =
-Dwrapper.cpu.time
out=3D"10" -Dwrapper.jvmid=3D1 com.silveregg.wrapper.WrapperSimpleApp =
P2PShell -Dshu
tdown.method=3DstopApplication -Dwindir=3DC:\WINDOWS" (ERR=3D2)
wrapper  | Critical error: wait for JVM process failed




  ----- Original Message -----=20
  From: Leif Mortenson=20
  To: wra...@li...=20
  Sent: Wednesday, November 27, 2002 10:22 AM
  Subject: Re: [Wrapper-user] environment variables


  Todd,
      Strange, All the wrapper does is call the standard Windows API to =
get the
  system environment variable's value.

      I just tested this on a Windows XP machine and on my machine I got =
the correct
  value:  C:\WINDOWS

      What do you get if you open a command prompt and type SET at the =
prompt?

      Do you see this problem when run as both a service and as a =
console app?  Or
  just one or the other?

      You might want to go in and look at the environment variable =
setting in the
  system control panel.  There are two sections.  User variables and =
system
  variables.  I have windir=3Dc:\windows in the system variables but no =
setting in the
  user section.  If the variable is set in both places, then you may be =
getting
  different values depending on context.

      Let me know whether or not any of this helps.

      Cheers,
      Leif


  Todd Enright wrote:

    I am using ver 2.2.9 on XP. =20
    The environment variable for WINDIR returning c:\winnt, but the =
actuall WINDIR variable on my machine is c:\windows, and further i don't =
have any c:\winnt directory on my machine. =20

    Do you know why this is happening?

Re: [Wrapper-user] environment variables

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

I just put a debug build of Wrapper.exe up on the server at
http://wrapper.sourceforge.net/Wrapper.exe
Can you BACKUP your current wrapper.exe and try it with this one?
It will dump out a bunch of debug info as it reads in the properties 
from the file.
Could you post what you get?

Thanks,
Leif

Todd Enright wrote:

> Hi Leif,
> The variable is set to c:\windows in the control panel, and this is 
> verified by going to a command prompt and typing SET.  I also have 
> windir=c:\windows in the system variables but no setting in the user 
> section.
>  
> I have get the same results by running wrapper as either a console 
> app, or a service.
>  
> I'll keep digging on my end. 
>
> Thanks,
> Todd
>
>     ----- Original Message -----
>     From: Leif Mortenson <mailto:le...@ta...>
>     To: wra...@li...
>     <mailto:wra...@li...>
>     Sent: Wednesday, November 27, 2002 10:22 AM
>     Subject: Re: [Wrapper-user] environment variables
>
>     Todd,
>         Strange, All the wrapper does is call the standard Windows API
>     to get the
>     system environment variable's value.
>
>         I just tested this on a Windows XP machine and on my machine I
>     got the correct
>     value:  C:\WINDOWS
>
>         What do you get if you open a command prompt and type SET at
>     the prompt?
>
>         Do you see this problem when run as both a service and as a
>     console app?  Or
>     just one or the other?
>
>         You might want to go in and look at the environment variable
>     setting in the
>     system control panel.  There are two sections.  User variables and
>     system
>     variables.  I have windir=c:\windows in the system variables but
>     no setting in the
>     user section.  If the variable is set in both places, then you may
>     be getting
>     different values depending on context.
>
>         Let me know whether or not any of this helps.
>
>         Cheers,
>         Leif
>
>
>     Todd Enright wrote:
>
>>     I am using ver 2.2.9 on XP. 
>>     The environment variable for WINDIR returning c:\winnt, but the
>>     actuall WINDIR variable on my machine is c:\windows, and further
>>     i don't have any c:\winnt directory on my machine. 
>>      
>>     Do you know why this is happening?
>
>

Re: [Wrapper-user] environment variables

[Todd E. <ten...@te...>]

Hi Leif,
The variable is set to c:\windows in the control panel, and this is =
verified by going to a command prompt and typing SET.  I also have =
windir=3Dc:\windows in the system variables but no setting in the user =
section.

I have get the same results by running wrapper as either a console app, =
or a service.

I'll keep digging on my end. =20

Thanks,
Todd
  ----- Original Message -----=20
  From: Leif Mortenson=20
  To: wra...@li...=20
  Sent: Wednesday, November 27, 2002 10:22 AM
  Subject: Re: [Wrapper-user] environment variables


  Todd,
      Strange, All the wrapper does is call the standard Windows API to =
get the
  system environment variable's value.

      I just tested this on a Windows XP machine and on my machine I got =
the correct
  value:  C:\WINDOWS

      What do you get if you open a command prompt and type SET at the =
prompt?

      Do you see this problem when run as both a service and as a =
console app?  Or
  just one or the other?

      You might want to go in and look at the environment variable =
setting in the
  system control panel.  There are two sections.  User variables and =
system
  variables.  I have windir=3Dc:\windows in the system variables but no =
setting in the
  user section.  If the variable is set in both places, then you may be =
getting
  different values depending on context.

      Let me know whether or not any of this helps.

      Cheers,
      Leif


  Todd Enright wrote:

    I am using ver 2.2.9 on XP. =20
    The environment variable for WINDIR returning c:\winnt, but the =
actuall WINDIR variable on my machine is c:\windows, and further i don't =
have any c:\winnt directory on my machine. =20

    Do you know why this is happening?

Re: [Wrapper-user] environment variables

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

Todd,
    Strange, All the wrapper does is call the standard Windows API to 
get the
system environment variable's value.

    I just tested this on a Windows XP machine and on my machine I got 
the correct
value:  C:\WINDOWS

    What do you get if you open a command prompt and type SET at the prompt?

    Do you see this problem when run as both a service and as a console 
app?  Or
just one or the other?

    You might want to go in and look at the environment variable setting 
in the
system control panel.  There are two sections.  User variables and system
variables.  I have windir=c:\windows in the system variables but no 
setting in the
user section.  If the variable is set in both places, then you may be 
getting
different values depending on context.

    Let me know whether or not any of this helps.

    Cheers,
    Leif


Todd Enright wrote:

> I am using ver 2.2.9 on XP. 
> The environment variable for WINDIR returning c:\winnt, but the 
> actuall WINDIR variable on my machine is c:\windows, and further i 
> don't have any c:\winnt directory on my machine. 
>  
> Do you know why this is happening?

[Wrapper-user] environment variables on XP

[Todd E. <ten...@te...>]

I am using ver 2.2.9 on XP. =20
The environment variable for WINDIR returning c:\winnt, but the actuall =
WINDIR variable on my machine is c:\windows, and further i don't have =
any c:\winnt directory on my machine. =20

Do you know why this is happening?

[Wrapper-user] environment variables

[Todd E. <ten...@te...>]

I am using ver 2.2.9 on XP. =20
The environment variable for WINDIR returning c:\winnt, but the actuall =
WINDIR variable on my machine is c:\windows, and further i don't have =
any c:\winnt directory on my machine. =20

Do you know why this is happening?

Re: [Wrapper-user] Re: Service stop while in delay

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

>
> Thanks a mill. Sorry I have not seen the list entries untill i 
> searched for them.
> I tested this now, and it works fine with the 2.2.9. (Cmpny intranet 
> does not have port for CVS open, unfortunately, yuck)

Unfortunately, that is a common problem.  You should point out that you 
need it for work.   Not any security
reasons why not to allow outgoing CVS connections.

> My product is in Final QA / Beta, will be released during the next two 
> months max.

Good luck.   What is the product?

Cheers,
Leif

[Wrapper-user] Re: Service stop while in delay

[Swart, N. <Nic...@ca...>]

Hi Leif,
Thanks a mill. Sorry I have not seen the list entries untill i searched for
them. 
I tested this now, and it works fine with the 2.2.9. (Cmpny intranet does
not have port for CVS open, unfortunately, yuck)
My product is in Final QA / Beta, will be released during the next two
months max.
Best regards,
nic

[Wrapper-user] Re: Plan to port to other platforms?

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

William,
I don't have access to either of those machines. A lot of people are
building on
Solaris and that supposedly works great. If you need these platforms, I
am afraid
that I am going to have to ask you to help get them working. I would
appreciate
it if you submitted any patches so that we could add support for those
platforms.
Feel free to ask me any questions and I will help where I can. I don't
think I am
using any unusual apis anywhere, so you might be lucky and have it come
pretty
close to compiling as is. Hope hope.

Cheers,
Leif

William Lee wrote:

>The Java Service Wrapper scripts look great and I got it to 
>work with the Tomcat 4 that I'm using currently.  The thing I'm 
>wondering is that whether it is easy/hard/very hard to port it to 
>AIX and HPUX, which my company need to support.  Do you 
>guys have a plan to do the port?  If you give me a few pointers 
>maybe you I can look into this myself.  Thanks.
>
>Will
>
>  
>

[Wrapper-user] Environment Variable Expansion Implemented in CVS

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

I finally got Environment Variable Expansion implemented. It is all
checked into CVS
and will be in the upcoming 2.2.9 release. I tested it out, but any help
pounding on
it before the releas would be appreciated.

From the dox:
Environment variable expansion

Starting with version 2.2.9, the Wrapper supports environment variable
expansion at run time within the values of any of the properties listed
on this page. To maintain the platform independent nature of the
wrapper.conf file, the windows syntax is used for all platforms.

Example referencing the JAVA_HOME environment variable:

wrapper.java.command=%JAVA_HOME%/bin/java

This will expand at runtime to a fully qualified path on any system
which defines the JAVA_HOME environment variable.

Windows:

wrapper.java.command=C:\Sun\jdk1.3/bin/java

Unix:

wrapper.java.command=/opt/IBMJava2-131/bin/java

If a referenced environment variable is not defined, then it will be
left unchanged in the property value.


Cheers,
Leif

Re: [Wrapper-user] Wrapper restarts GC'ing JVM - why?

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

Christian,
    The wrapper.cpu.timeout is used to detect when the entire machine 
freezes up.  Not
really the problem that you are having.  Leave it at the default.   This 
timeout is so either
process can handle a loss of CPU for its own internal timeouts.  In this 
case the Wrapper
process is timing out waiting for the Java process.

    In your case, the Wrapper is waiting for the specified 2 minutes, 
but the Java side GC
appears to be taking even longer to complete.   After two minutes, the 
Java process is
still effectively hung until the GC completes, so the Wrapper is doing 
as it is told and
assuming that since it has not received a ping response, the JVM is hung.

    Can you try extending the timeouts to a longer value?  Try 5 or 10 
minutes.  Make sure
to give it more time than your longest possible GC.  That should fix the 
problem.

    Let me know how it works.  If it does not fix the problem, please 
turn on the debug
output and post that.  It will give me more to work with.

Cheers,
Leif

Christian Beedgen wrote:

>Hi. While overall i am very pleased with the functionality and stability
>of the Wrapper, i just cannot seem to figure out one problem. I went
>through the docs and the mailing list archives, yet no idea. So here
>goes:
>
>The basic problem is that the Wrapper will restart my application if it
>takes too long to garbage collect (this is as per observation). Consider
>the following Wrapper log:
>
>INFO   | jvm 1    | 2002/10/14 13:43:49 | Memory Status: 112 MB Used,
>127 MB Total
>INFO   | jvm 1    | 2002/10/14 13:43:56 | [Full GC
>ERROR  | wrapper  | 2002/10/14 13:46:02 | JVM appears hung: Timed out
>waiting for signal from JVM.
>ERROR  | wrapper  | 2002/10/14 13:46:02 | Java Virtual Machine did not
>exit on request, terminated
>STATUS | wrapper  | 2002/10/14 13:46:08 | Launching a JVM...
>
>As can be seen, i am hitting the heap limit, at which point a full GC
>kicks in (JVM running in verbose mode). The machine the JVM is running
>on is short on main memory and hits the page file at this point,
>swapping for about two minutes (see timestamps) - finally, the Wrapper
>decides it's dead and restarts it.
>
>While i don't want to argue the fact the 2 minute GCs are pretty bad ;)
>- i still think the Wrapper should not have restarted the JVM. I have
>gone through most of the docs and tuned some of the advanced parameters,
>namely:
>
>wrapper.ping.timeout=120
>
>>From my understanding, this will make the Wrapper wait for 120 seconds
>if no pings get answered from the JVM, then decide it's dead. From the
>above log, it looks like this timeout is working (death comes after some
>2 minutes). Now i did look into the 
>
>wrapper.cpu.timeout=10
>
>parameter and left it at the default. my understanding is, that once the
>wrapper detects that either itself or the JVM is stalled, then the ping
>timeout is extended. from the docs, it looks like this functionality is
>there to address the problem i am describing above. however, in my case,
>it looks like the decision to restart is made before the stalled process
>detection kicks in - is this a bug or the expected behaviour? 
>
>I'd appreciate any help in figuring this out. Oh, and i've seen this on
>(underpowerd) Windows and Solaris boxen.
>
>
>thanks,
>
>
>chr. 
>  
>

[Wrapper-user] Wrapper restarts GC'ing JVM - why?

[Christian B. <chr...@be...>]

Hi. While overall i am very pleased with the functionality and stability
of the Wrapper, i just cannot seem to figure out one problem. I went
through the docs and the mailing list archives, yet no idea. So here
goes:

The basic problem is that the Wrapper will restart my application if it
takes too long to garbage collect (this is as per observation). Consider
the following Wrapper log:

INFO   | jvm 1    | 2002/10/14 13:43:49 | Memory Status: 112 MB Used,
127 MB Total
INFO   | jvm 1    | 2002/10/14 13:43:56 | [Full GC
ERROR  | wrapper  | 2002/10/14 13:46:02 | JVM appears hung: Timed out
waiting for signal from JVM.
ERROR  | wrapper  | 2002/10/14 13:46:02 | Java Virtual Machine did not
exit on request, terminated
STATUS | wrapper  | 2002/10/14 13:46:08 | Launching a JVM...

As can be seen, i am hitting the heap limit, at which point a full GC
kicks in (JVM running in verbose mode). The machine the JVM is running
on is short on main memory and hits the page file at this point,
swapping for about two minutes (see timestamps) - finally, the Wrapper
decides it's dead and restarts it.

While i don't want to argue the fact the 2 minute GCs are pretty bad ;)
- i still think the Wrapper should not have restarted the JVM. I have
gone through most of the docs and tuned some of the advanced parameters,
namely:

wrapper.ping.timeout=120

From my understanding, this will make the Wrapper wait for 120 seconds
if no pings get answered from the JVM, then decide it's dead. From the
above log, it looks like this timeout is working (death comes after some
2 minutes). Now i did look into the 

wrapper.cpu.timeout=10

parameter and left it at the default. my understanding is, that once the
wrapper detects that either itself or the JVM is stalled, then the ping
timeout is extended. from the docs, it looks like this functionality is
there to address the problem i am describing above. however, in my case,
it looks like the decision to restart is made before the stalled process
detection kicks in - is this a bug or the expected behaviour? 

I'd appreciate any help in figuring this out. Oh, and i've seen this on
(underpowerd) Windows and Solaris boxen.


thanks,


chr. 

Re: [Wrapper-user] Finding Memory Leaks (Was: Possible Enhancements)

[GMX <lg...@gm...>]

Leif,

Thank you for the explanation. I did indeed work with the profiler before,
but somehow often the problems are more subtle or do not show themselves
easily. Would be nice to have something like OpimizeIt to get this all
visually and being able to drill into each interactively. But for now the
built in profiler must suffice.

Kind regards,
Lars

[Wrapper-user] Finding Memory Leaks (Was: Possible Enhancements)

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

GMX wrote:

>Leif,
>
>Thanks for the reply, I will certainly looking into this. One issue why I
>was asking for a more external watchdog was that in case the system runs out
>of memory it often has some sort of fit, killing tasks and other nasty
>stuff. I fear that the hook to catch uncought excpetions might be failing as
>well. If you had this in the outside world as part of the watchdog process,
>you would not be affected by this. Does this make sense?
>
Yes, it makes sense.  I am not currently aware of any way to discover 
that a JVM is having
memory exceptions from outside of the JVM.

I think that you should actually be fairly successful at catching out of 
memory errors using the
uncaughtException method in ThreadGroups.  The reason is that your 
application will usually
run out of memory deep inside some method.  When the out of memory error 
is thrown, the
exception gets thrown all the way up the call stack until it is caught 
by the ThreadGroup and
sent to the uncaughtException method.   Each method call on a stack 
takes up memory, so
as the Exception gets cascaded up to the top, memory will be freed up. 
 Should be enough
in most cases to make it possible to call WrapperManager.restart from 
within the
uncaughtException method.

That is basically all that I would be able to do if this was added to 
the Java side of the
Wrapper.

It could be possible to monitor the memory usage of the Java process.   
But because of
the way Java's memory management works, I am not sure how I could tell 
whether Java
is really out of memory.  Java typically allocates more memory than it 
actually needs and
then internally does its own memory management.

The Runtime.totalMemory call returns the amount of memory allocated from 
the system.
Then the Runtime.freeMemory call returns how much of that memory is 
still available.

When freeMemory approaches 0, Java will first invoke GC.  If that does 
not free up very
much memory, then java will allocate more memory from the system.  It 
will stop allocating
memory from the system when it reaches the value set by -mx property set 
when the JVM
was launched.  Note that this defaults to 64MB even if your machine has 
a lot of memory.
You can set this in the wrapper using the wrapper.java.maxmemory property.

I am open to other ideas that you may have, but right now, I am not sure 
how the Wrapper
could do a better job of handling this problem.

>Of course, we have to fix the problem itself, but that is another story :-)
>
As for tracking down your memory problem.  The first thing I would 
suggest is to turn off
the JIT compiler using the -Djava.compiler=NONE property when launching 
the JVM.
(Not sure if that still works with Java 1.4  It does with 1.3 though.   
If your memory leak goes
away then from experience, it is most likely a problem caused by 
synchronization
someplace.   I have had similar problems in the past where JIT compiled 
code behaves
badly when you are having synchronization errors.  Non-JIT compiled code 
will still have
errors.  But the memory leaks and crashes seem to go away.

If that isn't the problem, then you may have an object leak someplace in 
your code.  Add the
following to the wrapper.conf.
wrapper.java.additional.5=-Xrunhprof:depth=8
wrapper.shutdown.timeout=0

The first enables object profiling.  When the JVM is asked to exit, it 
will dump this info to a file.
This can take several minutes depending how large your app is.  To keep 
the Wrapper from
thinking the JVM is hung, you want to disable shutdown timeouts.  Make 
sure to remove both
of these properties when you are done.

When the JVM exits you will see the following in the console or log file.
---
Dumping Java heap ... allocation sites ... done.
---

Look in the directory where Wrapper.exe is located and you will fine a 
file: java.hprof.txt
This file could be quite large, so I hope you have a good editor.

Search for "SITES BEGIN".  You will see a section towards the end of the 
file that looks
like this:
---
SITES BEGIN (ordered by live bytes) Fri Oct 11 12:56:48 2002
          percent         live       alloc'ed  stack class
 rank   self  accum    bytes objs   bytes objs trace name
    1  6.80%  6.80%   544264 4779  544264 4779     0 [C
    2  2.78%  9.59%   222624  964  223280  966  6361 [C
    3  2.14% 11.73%   171248 1262  173504 1299     1 [C
    4  2.12% 13.85%   169368  106  169368  106 17124 [B
    5  2.08% 15.93%   166736  183  166736  183     0 [B
    6  1.71% 17.64%   136624  397  208088  796 17100 [C
    7  1.55% 19.18%   123664  435  123664  435 16788 [C
---
This section is ordered by how much memory is being used by objects which
were created at specific places in the code.  If you are lucky, the 
first row will
be a very large number.
The second to the last column is the Trace number.  This says where the 
objects
 were created.   In the above example this is "4779".
To find out where these [C (Character Arrays) where created, do another 
search
for "TRACE 4779:"
I get the following:
---
TRACE 4779:
    java.lang.StringBuffer.toString(StringBuffer.java:1233)
    
org.apache.catalina.startup.Catalina.createContextCommon(Catalina.java:614)
    
org.apache.catalina.startup.Catalina.createStartMapperDefaultContext(Catalina.java:521)
    
org.apache.catalina.startup.Catalina.createStartMapper(Catalina.java:391)
    org.apache.catalina.startup.Catalina.start(Catalina.java:722)
    org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
    org.apache.catalina.startup.Catalina.process(Catalina.java:179)
    
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:Native 
method)
---
You may find that you need to increase the stack depth, but that takes 
more memory
and I usually find a depth of 8 to be sufficient.

Hope this helps you,
Cheers,
Leif