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

Re: [Wrapper-user] restart tuning

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

Anat,
    Currently, all restarts are viewed the same way by the Wrapper.  The 
thinking is that
something that happens shortly after startup is most likely a 
configuration or permanent
problem, where as something that happens after the application has been 
running for a
while is temporary and can be resolved by restarting.
    The wrapper.successful_invocation_time property defines this line.

    As you need to call restart once on startup, the max failed 
invocations needs to be
2.  Then you will need to define a wrapper.successful_invocation_time to 
prevent the
count from being reset.  The example below sets this time to 5 years.

wrapper.max_failed_invocations=2
wrapper.successful_invocation_time=157788000

    I can modify the wrapper.successful_invocation_time property so that 
a value of
0 will be interpreted as infinite time.  Would this make sense?

    How exactly would you like the Wrapper to behave?

Cheers,
Leif


Anat Halpern wrote:
> Thanks for your help, Leif.
>
> The first option is problematic, as the crash is not time-dependent.
> As for the option of using disable.restarts, I have to be able to call 
> WrapperManager.restart explicitly, at least once, (this is my 
> workaround for the GUI problem we discussed before - I restart the 
> application after I'm done with the GUI).
> So to make this clear, the problem is: explicit restarts are required, 
> but I'd still like to limit number of restarts on account of failure 
> in the run.
>
> According to the description of  max_failed_invocations: " Maximum 
> number of times that the Wrapper will attempt to restart the JVM if 
> each attempted invocation exits abnormally or...". In my case, the JVM 
> exists abnormally each time, but still the time factor is considered. 
> Is it possible to disregard the time and consider only the 
> success/failure of the run? If not, I think the documentation should 
> be changed a bit.
>
> Thanks a lot,
> Anat
>
> Leif Mortenson wrote:
>> Anat,
>>    If you use the wrapper.max_failed_invocations=1 property, you
>> will also need to set the wrapper.successful_invocation_time property to
>> a large value as you said.
>> http://wrapper.tanukisoftware.org/doc/english/prop-max-failed-invocations.html 
>>
>> http://wrapper.tanukisoftware.org/doc/english/prop-successful-invocation-time.html 
>>
>>
>>    Good news is that as of 3.2.0, there is a better way:
>> http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html
>>
>>    The only difference from your request is that all restarts are 
>> treated the
>> same way.  This is true with the above properties as well.
>>
>> Cheers,
>> Leif
>>
>> Anat Halpern wrote:
>>> Hi all,
>>> I'd like to disable all restarts except for explicit calls to 
>>> WrapperManager - is this possible?
>>>
>>> I've also tried to use the wrapper.max_failed_invocations, and it 
>>> did not work as I expected it to - the application kept  running for 
>>> a while before crashing, so it was considered a successful 
>>> invocation. Is there any way of making the wrapper ignore the 
>>> successful_invocation_time property (except setting it to a really 
>>> large number)?
>>>
>>> The problem I'm trying to deal with is that the application runs, 
>>> and then, depending on the input, crashes. The wrapper handled this 
>>> situation by restarting the application over and over, despite the 
>>> wrapper.max_failed_invocations=2.
>>> Any suggestions?
>>>
>>> Many thanks,
>>> Anat

Re: [Wrapper-user] restart tuning

[Anat H. <an...@en...>]

Thanks for your help, Leif.

The first option is problematic, as the crash is not time-dependent.
As for the option of using disable.restarts, I have to be able to call 
WrapperManager.restart explicitly, at least once, (this is my workaround 
for the GUI problem we discussed before - I restart the application 
after I'm done with the GUI).
So to make this clear, the problem is: explicit restarts are required, 
but I'd still like to limit number of restarts on account of failure in 
the run.

According to the description of  max_failed_invocations: " Maximum 
number of times that the Wrapper will attempt to restart the JVM if each 
attempted invocation exits abnormally or...". In my case, the JVM exists 
abnormally each time, but still the time factor is considered. Is it 
possible to disregard the time and consider only the success/failure of 
the run? If not, I think the documentation should be changed a bit.

Thanks a lot,
Anat

Leif Mortenson wrote:
> Anat,
>    If you use the wrapper.max_failed_invocations=1 property, you
> will also need to set the wrapper.successful_invocation_time property to
> a large value as you said.
> http://wrapper.tanukisoftware.org/doc/english/prop-max-failed-invocations.html 
>
> http://wrapper.tanukisoftware.org/doc/english/prop-successful-invocation-time.html 
>
>
>    Good news is that as of 3.2.0, there is a better way:
> http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html
>
>    The only difference from your request is that all restarts are 
> treated the
> same way.  This is true with the above properties as well.
>
> Cheers,
> Leif
>
> Anat Halpern wrote:
>> Hi all,
>> I'd like to disable all restarts except for explicit calls to 
>> WrapperManager - is this possible?
>>
>> I've also tried to use the wrapper.max_failed_invocations, and it did 
>> not work as I expected it to - the application kept  running for a 
>> while before crashing, so it was considered a successful invocation. 
>> Is there any way of making the wrapper ignore the 
>> successful_invocation_time property (except setting it to a really 
>> large number)?
>>
>> The problem I'm trying to deal with is that the application runs, and 
>> then, depending on the input, crashes. The wrapper handled this 
>> situation by restarting the application over and over, despite the 
>> wrapper.max_failed_invocations=2.
>> Any suggestions?
>>
>> Many thanks,
>> Anat
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.

Re: [Wrapper-user] Config File Naming

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

Jim,
    Yes.  It defaults to the base name of the exe + ".conf" in the same 
directory.  Works
the same on unix as well.

    This is all implemented, but CVS is down, so it is not yet committed.

    Cheers,
    Leif

Jim Redman wrote:
> Leif,
>
> Before I did through the code, does this "also" mean that you have 
> made the changes as proposed so that the wrapper configuration file 
> name follows the executable name or do I need to download the source 
> and make changes?
>
> Jim
>
> Leif Mortenson wrote:
>> Jim and all,
>>    Ok.  This sounds like a good idea.  I took the opportunity to also 
>> synchronize the
>> unix and Windows command line syntaxes.  Their old formats are now 
>> supported
>> everywhere.
>>
>>    Here is the new usage:
>> -----
>> C:\MyApp\bin>wrapper.exe
>> Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org
>>
>> Usage:
>>  wrapper.exe <command> <configuration file> [configuration 
>> properties] [...]
>>  wrapper.exe <configuration file> [configuration properties] [...]
>>     (<command> implicitly '-c')
>>  wrapper.exe <command>
>>     (<configuration file> implicitly 'wrapper.conf')
>>  wrapper.exe
>>     (<command> implicitly '-c' and <configuration file> 'wrapper.conf')
>>
>> where <command> can be one of:
>>  -c  --console run as a Console application
>>  -t  --start   starT an NT service
>>  -p  --stop    stoP a running NT service
>>  -i  --install Install as an NT service
>>  -r  --remove  Remove as an NT service
>>  -q  --query   Query the current status of the service
>>  -qs --querysilent Silently Query the current status of the service
>>  -?  --help    print this help message
>>
>> <configuration file> is the wrapper.conf to use.  Name must be 
>> absolute or relative
>>  to the location of wrapper.exe
>>
>> [configuration properties] are configuration name-value pairs which 
>> override values
>>  in wrapper.conf.  For example:
>>  wrapper.debug=true
>> -----
>>
>>    The Windows only commands are of course invalid on UNIX.
>>
>>    This is all implemented and will be in the 3.2.1 release.   
>> SourceForge's CVS is being
>> stubborn at the moment though, so I'll have to commit it later.
>>
>> Cheers,
>> Leif
>>
>> Jim Redman wrote:
>>> Does anyone else have a use for the feature where the name of the 
>>> config file maps to the name of the application?
>>>
>>> It allows two applications in the same directory without adding 
>>> arguments to the application and so is much cleaner.  For example,
>>>
>>> MyApp.exe looks for MyApp.conf
>>> AnotherApp.exe looks for AnotherApp.conf
>>>
>>> etc.  It then looks for wrapper.conf if the app-specific wrapper 
>>> does not exist.
>>>
>>> We need to make this change to the lastest exe.  If it's of general 
>>> interest, I'll try and do it cleanly and create a diff.  Otherwise 
>>> I'll just hack it in there.
>>>
>>> Jim
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Config File Naming

[Jim R. <jr...@er...>]

Leif,

Before I did through the code, does this "also" mean that you have made 
the changes as proposed so that the wrapper configuration file name 
follows the executable name or do I need to download the source and make 
changes?

Jim

Leif Mortenson wrote:
> Jim and all,
>    Ok.  This sounds like a good idea.  I took the opportunity to also 
> synchronize the
> unix and Windows command line syntaxes.  Their old formats are now 
> supported
> everywhere.
> 
>    Here is the new usage:
> -----
> C:\MyApp\bin>wrapper.exe
> Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org
> 
> Usage:
>  wrapper.exe <command> <configuration file> [configuration properties] 
> [...]
>  wrapper.exe <configuration file> [configuration properties] [...]
>     (<command> implicitly '-c')
>  wrapper.exe <command>
>     (<configuration file> implicitly 'wrapper.conf')
>  wrapper.exe
>     (<command> implicitly '-c' and <configuration file> 'wrapper.conf')
> 
> where <command> can be one of:
>  -c  --console run as a Console application
>  -t  --start   starT an NT service
>  -p  --stop    stoP a running NT service
>  -i  --install Install as an NT service
>  -r  --remove  Remove as an NT service
>  -q  --query   Query the current status of the service
>  -qs --querysilent Silently Query the current status of the service
>  -?  --help    print this help message
> 
> <configuration file> is the wrapper.conf to use.  Name must be absolute 
> or relative
>  to the location of wrapper.exe
> 
> [configuration properties] are configuration name-value pairs which 
> override values
>  in wrapper.conf.  For example:
>  wrapper.debug=true
> -----
> 
>    The Windows only commands are of course invalid on UNIX.
> 
>    This is all implemented and will be in the 3.2.1 release.   
> SourceForge's CVS is being
> stubborn at the moment though, so I'll have to commit it later.
> 
> Cheers,
> Leif
> 
> Jim Redman wrote:
>> Does anyone else have a use for the feature where the name of the 
>> config file maps to the name of the application?
>>
>> It allows two applications in the same directory without adding 
>> arguments to the application and so is much cleaner.  For example,
>>
>> MyApp.exe looks for MyApp.conf
>> AnotherApp.exe looks for AnotherApp.conf
>>
>> etc.  It then looks for wrapper.conf if the app-specific wrapper does 
>> not exist.
>>
>> We need to make this change to the lastest exe.  If it's of general 
>> interest, I'll try and do it cleanly and create a diff.  Otherwise 
>> I'll just hack it in there.
>>
>> Jim
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com

Re: [Wrapper-user] Config File Naming

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

Michael 'buk' Scherer wrote:
>> wrapper.exe
>>    (<command> implicitly '-c' and <configuration file> 'wrapper.conf')
>>     
> Does that mean
>   foobar.exe
>      (<command> implicitly '-c' and <configuration file> 'foobar.conf') ?
>   
That is correct.  The usage is generated dynamically based on the name 
of the binary.
>>   This is all implemented and will be in the 3.2.1 release.   SourceForge's
>> CVS is being stubborn at the moment though, so I'll have to commit it later.
>>     
> Switch to Berlios then. SF is broken really often and has lags for anymous 
> cvs...
> Just an idea. ;^)
>   
SF isn't always perfect.  But I have been happy with them over all.  
Been hosting the
project here since 2001 I believe.

Cheers,
Leif

Re: [Wrapper-user] log4j configuration issues

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

Karthikeyan,
    As I understand Log4j, that all looks fine.  You are specifying your 
properties file using
a system property so it does not need to be on the classpath.  I don't 
usually use log4j
however.  More a Apache Logkit fan.

    What happens if you add this:
wrapper.java.classpath.7=D:/rmi-svc/properties
    That will let logkit locate the file on the classpath.  The system 
property should be
working however.

    Try setting the following property to see the full java command used 
to launch the JVM:
wrapper.java.command.loglevel=INFO

    Not too helpful. :-/  Anyone else with more log4j experience have 
any ideas?

Cheers,
Leif
   


karthikeyan d wrote:
> Hi Leif,
>  
> Thanks for your time and willingness to solve my issues. Please find 
> attached the wrapper config file and my log4j.properties file.
>  
> Appreciate your support very much in this regard.
>  
>  
> Thanks & Regards,
> D.karthikeyan.
>  

Re: [Wrapper-user] restart tuning

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

Anat,
    If you use the wrapper.max_failed_invocations=1 property, you
will also need to set the wrapper.successful_invocation_time property to
a large value as you said.
http://wrapper.tanukisoftware.org/doc/english/prop-max-failed-invocations.html
http://wrapper.tanukisoftware.org/doc/english/prop-successful-invocation-time.html

    Good news is that as of 3.2.0, there is a better way:
http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html

    The only difference from your request is that all restarts are 
treated the
same way.  This is true with the above properties as well.

Cheers,
Leif

Anat Halpern wrote:
> Hi all,
> I'd like to disable all restarts except for explicit calls to 
> WrapperManager - is this possible?
>
> I've also tried to use the wrapper.max_failed_invocations, and it did 
> not work as I expected it to - the application kept  running for a 
> while before crashing, so it was considered a successful invocation. 
> Is there any way of making the wrapper ignore the 
> successful_invocation_time property (except setting it to a really 
> large number)?
>
> The problem I'm trying to deal with is that the application runs, and 
> then, depending on the input, crashes. The wrapper handled this 
> situation by restarting the application over and over, despite the 
> wrapper.max_failed_invocations=2.
> Any suggestions?
>
> Many thanks,
> Anat

[Wrapper-user] restart tuning

[Anat H. <an...@en...>]

Hi all,
I'd like to disable all restarts except for explicit calls to 
WrapperManager - is this possible?

I've also tried to use the wrapper.max_failed_invocations, and it did 
not work as I expected it to - the application kept  running for a while 
before crashing, so it was considered a successful invocation. Is there 
any way of making the wrapper ignore the successful_invocation_time 
property (except setting it to a really large number)?

The problem I'm trying to deal with is that the application runs, and 
then, depending on the input, crashes. The wrapper handled this 
situation by restarting the application over and over, despite the 
wrapper.max_failed_invocations=2.
Any suggestions?

Many thanks,
Anat

[Wrapper-user] log4j configuration issues

[karthikeyan d <bui...@gm...>]

#********************************************************************
#  Engine Wrapper Properties Configuration
# 
#********************************************************************

# Java Application

wrapper.java.command=C:/j2sdk1.4.2_10\bin\java

# Additional Information

wrapper.java.additional.1=-Dconfigfolder=D:/rmi-svc/config;D:/webDomain/tconfig;D:/webDomain/bconfig
wrapper.java.additional.2=-Dlog4j.configuration=D:/rmi-svc/properties/log4j.properties
wrapper.java.additional.3=-Dcastor.configuration=file:/D:/webDomain/properties/castor.properties
wrapper.java.additional.4=-Djava.security.auth.login.config=file:/D:/webDomain/properties/jaas.properties
wrapper.java.additional.5=-Djava.security.policy=file:/D:/rmi-svc/etc/java.policy

# 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=org.tanukisoftware.wrapper.test.Main

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1

wrapper.java.classpath.1=D:/libapp/wrapper.jar
wrapper.java.classpath.2=D:/webDomain/lib/log4j.jar
wrapper.java.classpath.3=D:/webDomain/lib/core.jar
wrapper.java.classpath.4=D:/webDomain/lib/utils.jar
wrapper.java.classpath.5=D:/libapp/engine.jar
wrapper.java.classpath.6=D:/webDomain/lib/xerces-1.4.5.jar




# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=D:/libapp
wrapper.java.library.path.2=D:/webDomain/lib

# 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=org.tanukisoftware.wrapper.WrapperStartStopApp

wrapper.app.parameter.1=com.wrapperHelperClasses.EngineStart
wrapper.app.parameter.2=0
wrapper.app.parameter.3=com.wrapperHelperClasses.EngineStop
wrapper.app.parameter.4=TRUE
wrapper.app.parameter.5=0
wrapper.app.parameter.6=0

# 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=

#wrapper debug
wrapper.debug=true

#port used by wrapper
wrapper.port=15013

# jvm exit timeout

wrapper.jvm_exit.timeout=120

# wrapper shutdown timeout

wrapper.shutdown.timeout=180

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# 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=DEBUG

# Log file to use for wrapper output logging.
wrapper.logfile=D:/logs/wrapperEngine.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=STATUS

# 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=1m

# 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=5

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

#********************************************************************
# Wrapper Windows Properties
#********************************************************************
# Title to use when running as a console
wrapper.console.title= ENGINE CONSOLE

#********************************************************************
# 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.ntservice.name=ENGINE

# Display name of the service
wrapper.ntservice.displayname=ENGINE AS SERVICE

# Description of the service
wrapper.ntservice.description=ENGINE AS SERVICE

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

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

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

Re: [Wrapper-user] log4j configuration issues

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

Karthikeyan,
    Can you post your wrapper.conf so I can see exactly what you are 
doing.  Log4j will
either locate its properties file using a system property, or by 
locating the file on the
classpath.  If you have this file in your conf directory, you will need 
a class path entry
like the following:
wrapper.java.classpath.1=../lib/*.jar
wrapper.java.classpath.2=../conf

Cheers,
Leif

karthikeyan d wrote:
> Hi,
> i am using java service wrapper to run my java application as a 
> windows service. while running the application i am able to get the 
> logs written to the wrapper specific files but not to application 
> specific log files. The application's java class log statements are 
> not logging because of the warning i am getting
>  
>
> jvm 1    | log4j:WARN No appenders could be found for logger (My Class 
> name).
>
> jvm 1    | log4j:WARN Please initialize the log4j system properly.
>
>  
>
> i am using the log4j-properties file for log4j configuration. i am 
> passing this to java command at runtime and log4j.jar file is in the 
> classpath. i tried putting the properties file in the folder that 
> contains the wrapper.exe but still it didn't help. In my 
> log4j-properties file i am using the absolute location for the 
> differrent properties and all are valid entries. i browsed through all 
> the log4j related posts in the site but still i need your valuable 
> assistance in resolving my issues.
>
>  
>
>  
>
> Thanks in advance,
>
>  
>
> Regards,
>
> D.Karthikeyan.
>
>  
>
>  
>

[Wrapper-user] log4j configuration issues

[karthikeyan d <bui...@gm...>]

Hi,
i am using java service wrapper to run my java application as a windows
service. while running the application i am able to get the logs written to
the wrapper specific files but not to application specific log files. The
application's java class log statements are not logging because of the
warning i am getting


jvm 1    | log4j:WARN No appenders could be found for logger (My Class
name).

jvm 1    | log4j:WARN Please initialize the log4j system properly.



i am using the log4j-properties file for log4j configuration. i am passing
this to java command at runtime and log4j.jar file is in the classpath. i
tried putting the properties file in the folder that contains the
wrapper.exe but still it didn't help. In my log4j-properties file i am usin=
g
the absolute location for the differrent properties and all are valid
entries. i browsed through all the log4j related posts in the site but stil=
l
i need your valuable assistance in resolving my issues.





Thanks in advance,



Regards,

D.Karthikeyan.

Re: [Wrapper-user] Config File Naming

[Michael 'b. S. <msc...@gi...>]

Good morning.

On Fri, 31 Mar 2006 - 12:57pm, Leif Mortenson wrote:

> wrapper.exe
>    (<command> implicitly '-c' and <configuration file> 'wrapper.conf')

Does that mean
  foobar.exe
     (<command> implicitly '-c' and <configuration file> 'foobar.conf') ?


>   This is all implemented and will be in the 3.2.1 release.   SourceForge's
> CVS is being stubborn at the moment though, so I'll have to commit it later.
Switch to Berlios then. SF is broken really often and has lags for anymous 
cvs...
Just an idea. ;^)


Greetings,
 Michael

-- 
  I love deadlines, especially the sound they make as they go whooshing by.

Re: [Wrapper-user] Re: AIX only: Wrapper receives an immediate request to shutdown from the JVM

[Clever M. <clv...@gm...>]

On 30-Mar-06, at 9:52 PM, Leif Mortenson wrote:
>
>    I was not able to do a 3.2.0 release for AIX because the person  
> who normally
> helps out couldn't do so this time.  But the build should work.   
> This new version
> contains a couple new properties which help with this kind of problem.
> http://wrapper.tanukisoftware.org/doc/english/prop-monitor-thread- 
> count.html
> http://wrapper.tanukisoftware.org/doc/english/prop-thread-count- 
> delay.html
>
I'll take a look.

>    The 3.1.2 release has had over 1000 AIX downloads and I have not  
> heard
> any reports of this from other users.  This makes me think that it  
> is not an AIX
> wide problem, but rather a problem with a specific JVM implementation.
> What is the value of the java.fullversion, java.runtime.version,  
> and java.vm.name
> system properties that you are using?
> You can get the information I need by copying the following from  
> your wrapper.log
> with the wrapper.debug=true property set:
> jvm 1    | Java Version   : 1.4.2_08-b03 Java HotSpot(TM) Client VM
> jvm 1    | Java VM Vendor : Sun Microsystems Inc.
>
This is the official Java 1.5 RC1 release from IBM.  I suspect your  
other 3.1.2 users are launching Java 1.4 apps, and that something has  
changed a bit since.  This is not out of the realm of possibilities,  
considering how new Java 1.5 is for AIX.

The VM information is in my first email, no?  The output I attached  
was created by running with debug=true.  I'll repeat the information  
for your convenience:

INFO   | 2006/03/30 12:26:45 | Java Version   : J2RE 1.5.0 IBM J9 2.3
AIX ppc-32 j9vmap3223ifx-20060310 (JIT enabled)
INFO   | 2006/03/30 12:26:45 | J9VM - 20060220_05389_bHdSMR
INFO   | 2006/03/30 12:26:45 | JIT  - 20060220_2133_r8
INFO   | 2006/03/30 12:26:45 | GC   - 20060214_AA
INFO   | 2006/03/30 12:26:45 | Java VM Vendor : IBM Corporation

The solution for us was to tweak the way that the shutdown thread is  
accounted for in WrapperManager.  I can send the debugging output I  
enabled by recompiling WrapperManager with the trivial debugging  
(which was commented out) that shows it cycling through the threads  
looking for non-daemon alive threads.

We only ever get "1" of these threads when the VM first comes up, so  
Wrapper kills the VM.  Either the test is wrong, or the vlaue we are  
testing against (either 0 or 1) is wrong.  It looks like Java 5 RC1  
on AIX from IBM is more like the WebLogic VM in this regard.

If your new properties control these values, then that should be  
sufficient for us.  For this release we may have to run with my  
changes until I can update our thirdparty resources for next release.

Thanks.

-- John

Re: [Wrapper-user] Config File Naming

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

Jim and all,
    Ok.  This sounds like a good idea.  I took the opportunity to also 
synchronize the
unix and Windows command line syntaxes.  Their old formats are now supported
everywhere.

    Here is the new usage:
-----
C:\MyApp\bin>wrapper.exe
Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org

Usage:
  wrapper.exe <command> <configuration file> [configuration properties] 
[...]
  wrapper.exe <configuration file> [configuration properties] [...]
     (<command> implicitly '-c')
  wrapper.exe <command>
     (<configuration file> implicitly 'wrapper.conf')
  wrapper.exe
     (<command> implicitly '-c' and <configuration file> 'wrapper.conf')

where <command> can be one of:
  -c  --console run as a Console application
  -t  --start   starT an NT service
  -p  --stop    stoP a running NT service
  -i  --install Install as an NT service
  -r  --remove  Remove as an NT service
  -q  --query   Query the current status of the service
  -qs --querysilent Silently Query the current status of the service
  -?  --help    print this help message

<configuration file> is the wrapper.conf to use.  Name must be absolute 
or relative
  to the location of wrapper.exe

[configuration properties] are configuration name-value pairs which 
override values
  in wrapper.conf.  For example:
  wrapper.debug=true
-----

    The Windows only commands are of course invalid on UNIX.

    This is all implemented and will be in the 3.2.1 release.   
SourceForge's CVS is being
stubborn at the moment though, so I'll have to commit it later.

Cheers,
Leif

Jim Redman wrote:
> Does anyone else have a use for the feature where the name of the 
> config file maps to the name of the application?
>
> It allows two applications in the same directory without adding 
> arguments to the application and so is much cleaner.  For example,
>
> MyApp.exe looks for MyApp.conf
> AnotherApp.exe looks for AnotherApp.conf
>
> etc.  It then looks for wrapper.conf if the app-specific wrapper does 
> not exist.
>
> We need to make this change to the lastest exe.  If it's of general 
> interest, I'll try and do it cleanly and create a diff.  Otherwise 
> I'll just hack it in there.
>
> Jim
>

Re: [Wrapper-user] Re: AIX only: Wrapper receives an immediate request to shutdown from the JVM

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

Mr Monkey,
    I was not able to do a 3.2.0 release for AIX because the person who 
normally
helps out couldn't do so this time.  But the build should work.  This 
new version
contains a couple new properties which help with this kind of problem.
http://wrapper.tanukisoftware.org/doc/english/prop-monitor-thread-count.html
http://wrapper.tanukisoftware.org/doc/english/prop-thread-count-delay.html

    The 3.1.2 release has had over 1000 AIX downloads and I have not heard
any reports of this from other users.  This makes me think that it is 
not an AIX
wide problem, but rather a problem with a specific JVM implementation.
What is the value of the java.fullversion, java.runtime.version, and 
java.vm.name
system properties that you are using?
You can get the information I need by copying the following from your 
wrapper.log
with the wrapper.debug=true property set:
jvm 1    | Java Version   : 1.4.2_08-b03 Java HotSpot(TM) Client VM
jvm 1    | Java VM Vendor : Sun Microsystems Inc.

    Cheers,
    Leif

Clever Monkey wrote:
>
> On 30-Mar-06, at 2:04 PM, clvrmnky wrote:
>
>> Wrapper 3.1.2
>> AIX 5.2
>> Java 5
>>
>> Similar to 
>> <http://sourceforge.net/mailarchive/message.php?msg_id=9831093>,
>> I am having a problem getting our JVM to launch our JBoss app.  This
>> is only a problem on AIX for us.
>>
>> I'm working on ensuring the correct APARs for AIX to run a Java 5 RC 1
>> VM have been applied, in case this is a VM issue (so far, I think the
>> system is patched to the level it needs to be).  I _can_ run and
>> launch the sample app at version 3.1.2 I downloaded from SourceForge,
>> though when I hack in the sample wrapper executable into our app I get
>> the same problem.  I've attached the output from wrapper.debug=true.
>>
> Looks like the Java 5 RC1 JVM on AIX does not have a shutdown thread.  
> I made "AIX" a special case (like WebLogic) in WrapperManager and it 
> seems to fire up nicely.

[Wrapper-user] Re: AIX only: Wrapper receives an immediate request to shutdown from the JVM

[Clever M. <clv...@gm...>]

On 30-Mar-06, at 2:04 PM, clvrmnky wrote:

> Wrapper 3.1.2
> AIX 5.2
> Java 5
>
> Similar to <http://sourceforge.net/mailarchive/message.php? 
> msg_id=9831093>,
> I am having a problem getting our JVM to launch our JBoss app.  This
> is only a problem on AIX for us.
>
> I'm working on ensuring the correct APARs for AIX to run a Java 5 RC 1
> VM have been applied, in case this is a VM issue (so far, I think the
> system is patched to the level it needs to be).  I _can_ run and
> launch the sample app at version 3.1.2 I downloaded from SourceForge,
> though when I hack in the sample wrapper executable into our app I get
> the same problem.  I've attached the output from wrapper.debug=true.
>
Looks like the Java 5 RC1 JVM on AIX does not have a shutdown  
thread.  I made "AIX" a special case (like WebLogic) in  
WrapperManager and it seems to fire up nicely.

[Wrapper-user] AIX only: Wrapper receives an immediate request to shutdown from the JVM

[clvrmnky <clv...@gm...>]

Wrapper 3.1.2
AIX 5.2
Java 5

Similar to <http://sourceforge.net/mailarchive/message.php?msg_id=3D9831093=
>,
I am having a problem getting our JVM to launch our JBoss app.  This
is only a problem on AIX for us.

I'm working on ensuring the correct APARs for AIX to run a Java 5 RC 1
VM have been applied, in case this is a VM issue (so far, I think the
system is patched to the level it needs to be).  I _can_ run and
launch the sample app at version 3.1.2 I downloaded from SourceForge,
though when I hack in the sample wrapper executable into our app I get
the same problem.  I've attached the output from wrapper.debug=3Dtrue.

Now, to be perfectly clear, we recompile wrapper from scratch so the
service name is prettier and matches our product name (here changed to
"fnord").  The names of the login, company and product have been
changed to protect the potentially stupid.  Namely, me.

Notes on the .conf file.  These were added to help debug things, and
do not change the behaviour I'm seeing here:
fnord.java.additional.21=3D-verbose:jni
fnord.java.additional.22=3D-Xcheck:jni
fnord.java.additional.23=3D-Dorg.tanukisoft.wrapper.WrapperSimpleApp.maxSta=
rtMainWait=3D30

Can anyone shed some light on this?  I accept that it could be the VM
(IBM has a wonderfully tweaked VM that can be an utter joy to work
with), but all I can see is that wrapperProtocolRead() reads
WRAPPER_MSG_STOP.  Advice on how to find out why would be much
appreciated.

One note is that I cannot simply update Wrapper to some other revision
unless I am really sure it will solve the problem.  We have a pretty
tight control on changes this late in the release cycle, and every
other Unix system we support seems to work fine.  Just FYI.

--
clvrmnky <mailto:clv...@gm...>

[startup.log]
STATUS | 2006/03/30 12:26:37 | --> Fnord World Domination Server 2006
Started as Console
DEBUG  | 2006/03/30 12:26:37 | Using system timer.
DEBUG  | 2006/03/30 12:26:37 | server listening on port 32000.
DEBUG  | 2006/03/30 12:26:37 | Command[0] :
/home/clvrmnky/servers/3817aix/jre/bin/java
DEBUG  | 2006/03/30 12:26:37 | Command[1] : -Xms512m
DEBUG  | 2006/03/30 12:26:37 | Command[2] : -Xmx512m
DEBUG  | 2006/03/30 12:26:37 | Command[3] :
-Xbootclasspath/p:/home/clvrmnky/servers/3817aix/server/fnord/patch/patchfn=
ordboot/classes:/home/clvrmnky/servers/3817aix/server/fnord/patch/patchfnor=
dboot.jar:/home/clvrmnky/servers/3817aix/server/fnord/lib/boot/fnordboot.ja=
r
DEBUG  | 2006/03/30 12:26:37 | Command[4] : -Xss256k
DEBUG  | 2006/03/30 12:26:37 | Command[5] : -Dprogram.name=3Drun.bat
DEBUG  | 2006/03/30 12:26:37 | Command[6] : -Djboss.identity.domain=3DFNORD
DEBUG  | 2006/03/30 12:26:37 | Command[7] : -Dfnord.safemode=3Dfalse
DEBUG  | 2006/03/30 12:26:37 | Command[8] : -Dfnord.safemode.password=3D<se=
cret>
DEBUG  | 2006/03/30 12:26:37 | Command[9] : -Dfnord.unattended.startup=3Dtr=
ue
DEBUG  | 2006/03/30 12:26:37 | Command[10] : -Dfnord.master.key=3Dfake_mast=
er_key
DEBUG  | 2006/03/30 12:26:37 | Command[11] : -Dfnord.dynamic.aop=3Dfalse
DEBUG  | 2006/03/30 12:26:37 | Command[12] : -Dxmbean.metadata.xml.validate=
=3Dtrue
DEBUG  | 2006/03/30 12:26:37 | Command[13] :
-Dfnordis.neurondir=3D/home/clvrmnky/servers/3817aix/server/fnord/bin
DEBUG  | 2006/03/30 12:26:37 | Command[14] :
-Djboss.server.base.dir=3D/home/clvrmnky/servers/3817aix/server
DEBUG  | 2006/03/30 12:26:37 | Command[15] :
-Djboss.server.base.url=3Dfile:///home/clvrmnky/servers/3817aix/server
DEBUG  | 2006/03/30 12:26:37 | Command[16] :
-Djava.endorsed.dirs=3D/home/clvrmnky/servers/3817aix/server/lib/endorsed
DEBUG  | 2006/03/30 12:26:37 | Command[17] : -Djava.awt.headless=3Dtrue
DEBUG  | 2006/03/30 12:26:37 | Command[18] :
-Dfnord.installDir=3D/home/clvrmnky/servers/3817aix
DEBUG  | 2006/03/30 12:26:37 | Command[19] : -Dfnord.install=3Dserver
DEBUG  | 2006/03/30 12:26:37 | Command[20] : -verbose:jni
DEBUG  | 2006/03/30 12:26:37 | Command[21] : -Xcheck:jni
DEBUG  | 2006/03/30 12:26:37 | Command[22] :
-Dorg.tanukisoft.wrapper.WrapperSimpleApp.maxStartMainWait=3D300
DEBUG  | 2006/03/30 12:26:37 | Command[23] :
-Djava.library.path=3D/home/clvrmnky/servers/3817aix/server/lib:/home/clvrm=
nky/servers/3817aix/server/fnord/bin
DEBUG  | 2006/03/30 12:26:37 | Command[24] : -classpath
DEBUG  | 2006/03/30 12:26:37 | Command[25] :
/home/clvrmnky/servers/3817aix/server/lib/fnordservice.jar:/home/clvrmnky/s=
ervers/3817aix/server/bin/run.jar
DEBUG  | 2006/03/30 12:26:37 | Command[26] : -Dwrapper.key=3DFyIsmbXc06V1kO=
_V
DEBUG  | 2006/03/30 12:26:37 | Command[27] : -Dwrapper.port=3D32000
DEBUG  | 2006/03/30 12:26:37 | Command[28] : -Dwrapper.debug=3DTRUE
DEBUG  | 2006/03/30 12:26:37 | Command[29] : -Dwrapper.use_system_time=3DTR=
UE
DEBUG  | 2006/03/30 12:26:37 | Command[30] : -Dwrapper.version=3D3.1.2
DEBUG  | 2006/03/30 12:26:37 | Command[31] :
-Dwrapper.native_library=3Dfnordservice
DEBUG  | 2006/03/30 12:26:37 | Command[32] : -Dwrapper.cpu.timeout=3D10
DEBUG  | 2006/03/30 12:26:37 | Command[33] : -Dwrapper.jvmid=3D1
DEBUG  | 2006/03/30 12:26:37 | Command[34] :
org.tanukisoftware.wrapper.WrapperSimpleApp
DEBUG  | 2006/03/30 12:26:37 | Command[35] : org.jboss.Main
DEBUG  | 2006/03/30 12:26:37 | Command[36] : -c
DEBUG  | 2006/03/30 12:26:37 | Command[37] : fnord
STATUS | 2006/03/30 12:26:37 | Launching a JVM...
INFO   | 2006/03/30 12:26:38 | JVMJNCK001I JNI check utility
installed. Use -Xcheck:jni:help for usage
INFO   | 2006/03/30 12:26:44 | WrapperManager class initialized by
thread: main  Using classloader:
sun.misc.Launcher$AppClassLoader@2ff02ff0
INFO   | 2006/03/30 12:26:44 | Wrapper Manager: JVM #1
INFO   | 2006/03/30 12:26:44 | Wrapper Manager: Registering shutdown hook
INFO   | 2006/03/30 12:26:44 | Wrapper Manager: Using wrapper
INFO   | 2006/03/30 12:26:45 | Loaded native library: libfnordservice.so
INFO   | 2006/03/30 12:26:45 | Calling native initialization method.
INFO   | 2006/03/30 12:26:45 | Inside native WrapperManager
initialization method
INFO   | 2006/03/30 12:26:45 | Java Version   : J2RE 1.5.0 IBM J9 2.3
AIX ppc-32 j9vmap3223ifx-20060310 (JIT enabled)
INFO   | 2006/03/30 12:26:45 | J9VM - 20060220_05389_bHdSMR
INFO   | 2006/03/30 12:26:45 | JIT  - 20060220_2133_r8
INFO   | 2006/03/30 12:26:45 | GC   - 20060214_AA
INFO   | 2006/03/30 12:26:45 | Java VM Vendor : IBM Corporation
INFO   | 2006/03/30 12:26:45 |
INFO   | 2006/03/30 12:26:45 | Wrapper (Version 3.1.2)
http://wrapper.tanukisoftware.org
INFO   | 2006/03/30 12:26:45 |
INFO   | 2006/03/30 12:26:45 |
WrapperManager.start(org.tanukisoftware.wrapper.WrapperSimpleApp@7d6c7d6c,
args["-c", "fnord"]) called by thread: main
INFO   | 2006/03/30 12:26:45 | Open socket to wrapper...
DEBUG  | 2006/03/30 12:26:46 | accepted a socket from 127.0.0.1 on port 365=
52
INFO   | 2006/03/30 12:26:46 | Opened Socket
INFO   | 2006/03/30 12:26:46 | Send a packet KEY : FyIsmbXc06V1kO_V
INFO   | 2006/03/30 12:26:46 |
handleSocket(Socket[addr=3Dlocalhost/127.0.0.1,port=3D32000,localport=3D365=
52])
DEBUG  | 2006/03/30 12:26:46 | read a packet KEY : FyIsmbXc06V1kO_V
DEBUG  | 2006/03/30 12:26:46 | Got key from JVM: FyIsmbXc06V1kO_V
DEBUG  | 2006/03/30 12:26:46 | send a packet LOW_LOG_LEVEL : 1
DEBUG  | 2006/03/30 12:26:46 | send a packet PING_TIMEOUT : 300
DEBUG  | 2006/03/30 12:26:46 | Start Application.
DEBUG  | 2006/03/30 12:26:46 | send a packet START : start
INFO   | 2006/03/30 12:26:46 | Received a packet LOW_LOG_LEVEL : 1
INFO   | 2006/03/30 12:26:46 | Wrapper Manager: LowLogLevel from Wrapper is=
 1
INFO   | 2006/03/30 12:26:46 | Received a packet PING_TIMEOUT : 300
INFO   | 2006/03/30 12:26:46 | Wrapper Manager: PingTimeout from
Wrapper is 300000
INFO   | 2006/03/30 12:26:46 | Received a packet START : start
INFO   | 2006/03/30 12:26:46 | calling listener.start()
INFO   | 2006/03/30 12:26:46 | WrapperSimpleApp: start(args)
INFO   | 2006/03/30 12:26:46 | WrapperSimpleApp: invoking main method
INFO   | 2006/03/30 12:26:46 | WrapperSimpleApp: main method completed
INFO   | 2006/03/30 12:26:46 | WrapperSimpleApp: start(args) end.=20
Main Completed=3Dtrue, exitCode=3Dnull
INFO   | 2006/03/30 12:26:46 | returned from listener.start()
INFO   | 2006/03/30 12:26:46 | Send a packet STARTED :
INFO   | 2006/03/30 12:26:46 | All non-daemon threads have stopped.  Exitin=
g.
INFO   | 2006/03/30 12:26:46 | WrapperManager.stop(0) called by
thread: Wrapper-Connection
INFO   | 2006/03/30 12:26:46 | Send a packet STOP : 0
DEBUG  | 2006/03/30 12:26:46 | read a packet STARTED :
DEBUG  | 2006/03/30 12:26:46 | JVM signalled that it was started.
DEBUG  | 2006/03/30 12:26:46 | read a packet STOP : 0
DEBUG  | 2006/03/30 12:26:46 | JVM requested a shutdown. (0)
DEBUG  | 2006/03/30 12:26:46 | wrapperStopProcess(0) called.
DEBUG  | 2006/03/30 12:26:46 | Sending stop signal to JVM
DEBUG  | 2006/03/30 12:26:46 | send a packet STOP : NULL
INFO   | 2006/03/30 12:26:47 | Thread, Wrapper-Connection, handling
the shutdown process.
INFO   | 2006/03/30 12:26:47 | calling listener.stop()
INFO   | 2006/03/30 12:26:47 | WrapperSimpleApp: stop(0)
INFO   | 2006/03/30 12:26:47 | returned from listener.stop()
INFO   | 2006/03/30 12:26:47 | Send a packet STOPPED : 0
DEBUG  | 2006/03/30 12:26:47 | read a packet STOPPED : 0
DEBUG  | 2006/03/30 12:26:47 | JVM signalled that it was stopped.
INFO   | 2006/03/30 12:26:47 | Closing socket.
DEBUG  | 2006/03/30 12:26:47 | socket read no code (closed?).
INFO   | 2006/03/30 12:26:48 | calling System.exit(0)
DEBUG  | 2006/03/30 12:26:48 | JVM process exited with a code of 0,
leaving the wrapper exit code set to 0.
DEBUG  | 2006/03/30 12:26:48 | JVM exited normally.
STATUS | 2006/03/30 12:26:48 | <-- Fnord World Domination Server 2006 Stopp=
ed

[fnordservice.conf]
#*********************************************************************
# FNORD World Domination Server Properties
#*********************************************************************

#*********************************************************************
# Title to use when running as a console.  It is also used in some messages=
.
# The default is set to "FNORD World Domination Server YYYY".
#*********************************************************************
fnord.console.title=3DFNORD World Domination Server 2006

# Log file to use for output logging; default is startup.log.
fnord.logfile=3D/home/clvrmnky/servers/3817aix/log/startup.log

# The name of the Java Native Library (JNI)
fnord.native_library=3Dfnordservice

#*********************************************************************
# fnord.java.additonal.<n>
#   Additional Java parameters to pass to Java when it is launched.
#   These are the parameters for the Java Virtual Machine.
#   Each element has a property name which starts with fnord.java.additiona=
l.
#   and ends with a unique number between 1 and 60. The numbering
#   and ordering in the file need not be continuous, but avoid duplicates.
#*********************************************************************
fnord.java.additional.1=3D-Xms512m
fnord.java.additional.2=3D-Xmx512m
fnord.java.additional.3=3D-Xbootclasspath/p:/home/clvrmnky/servers/3817aix/=
server/fnord/patch/patchfnordboot/classes:/home/clvrmnky/servers/3817aix/se=
rver/fnord/patch/patchfnordboot.jar:/home/clvrmnky/servers/3817aix/server/f=
nord/lib/boot/fnordboot.jar
fnord.java.additional.4=3D-Xss256k
fnord.java.additional.5=3D-Dprogram.name=3Drun.bat
fnord.java.additional.6=3D-Djboss.identity.domain=3DFNORD
fnord.java.additional.7=3D-Dfnord.safemode=3Dfalse
fnord.java.additional.8=3D-Dfnord.safemode.password=3D<secret>
fnord.java.additional.9=3D-Dfnord.unattended.startup=3Dtrue
fnord.java.additional.10=3D-Dfnord.master.key=3Dfake_master_key
fnord.java.additional.11=3D-Dfnord.dynamic.aop=3Dfalse
fnord.java.additional.12=3D-Dxmbean.metadata.xml.validate=3Dtrue
fnord.java.additional.13=3D-Dfnordis.neurondir=3D/home/clvrmnky/servers/381=
7aix/server/fnord/bin
fnord.java.additional.14=3D-Djboss.server.base.dir=3D/home/clvrmnky/servers=
/3817aix/server
fnord.java.additional.15=3D-Djboss.server.base.url=3Dfile:///home/clvrmnky/=
servers/3817aix/server
fnord.java.additional.17=3D-Djava.endorsed.dirs=3D/home/clvrmnky/servers/38=
17aix/server/lib/endorsed
fnord.java.additional.18=3D-Djava.awt.headless=3Dtrue
fnord.java.additional.19=3D-Dfnord.installDir=3D/home/clvrmnky/servers/3817=
aix
fnord.java.additional.20=3D-Dfnord.install=3Dserver
fnord.java.additional.21=3D-verbose:jni
fnord.java.additional.22=3D-Xcheck:jni
fnord.java.additional.23=3D-Dorg.tanukisoft.wrapper.WrapperSimpleApp.maxSta=
rtMainWait=3D300
#fnord.java.additional.21=3D-server
#fnord.java.additional.22=3D-XX:MaxPermSize=3D128m

# The command to use when launching a JVM.
fnord.java.command=3D/home/clvrmnky/servers/3817aix/jre/bin/java

#*********************************************************************
# Other Properties - modify these only under advice of FNORD services team
#*********************************************************************

#*********************************************************************
# fnord.java.classpath.<n> --- Java Classpath to use.
#   Each element has a property name which starts with fnord.java.classpath=
.
#   and ends with a unique number between 1 and 40. The numbering
#   and ordering in the file need not be continuous, but avoid duplicates.
#*********************************************************************
fnord.java.classpath.1=3D/home/clvrmnky/servers/3817aix/server/lib/fnordser=
vice.jar
fnord.java.classpath.2=3D/home/clvrmnky/servers/3817aix/server/bin/run.jar

# Class to execute when the service starts the application.
fnord.java.mainclass=3Dorg.tanukisoftware.wrapper.WrapperSimpleApp

#*********************************************************************
# fnord.app.parameter.<n>
#   Application parameters to pass to the application when it is launched.
#   Each element has a property name which starts with fnord.java.parameter=
.
#   and ends with a unique number between 1 and 40. The numbering
#   and ordering in the file need not be continuous, but avoid duplicates.
#*********************************************************************
fnord.app.parameter.1=3Dorg.jboss.Main
fnord.app.parameter.2=3D-c
fnord.app.parameter.3=3Dfnord

#*********************************************************************
# Format of output for console.  The format consists of the tokens
#       'L' for log level,
#       'D' for thread,
#       'T' for time, and
#       'M' for message.
# If the property is missing or commented out, then the default value 'M'
# will be used.  Setting the property to blank will disable console output.
# E.g. fnord.console.format=3DLTM
#       STATUS | 2005/11/16 11:00:25 | --> FNORD Started as Console
#=09STATUS | 2005/11/16 11:00:25 | Launching a JVM...
#*********************************************************************
fnord.console.format=3DM

#*********************************************************************
# Log level for console output.  Valid log levels include:
#       NONE for no output,
#       FATAL to only show fatal error messages,
#       ERROR to show all error messages,
#       STATUS to show all state changes (the default),
#       INFO to show all JVM output and informative messages, and
#       DEBUG to show detailed debug information.
# Default is STATUS. Note that at STATUS level, hitting CTRL-BREAK does
# not produce a stack trace when running in console mode.
#*********************************************************************
fnord.console.loglevel=3DDEBUG

#*********************************************************************
# Format of output for log file.  The format consists of the tokens
#       'L' for log level,
#       'D' for thread,
#       'T' for time, and
#       'M' for message.
# If the property is missing or commented out, then the default value 'LTM'
# will be used.  Setting the property to blank will disable file logging.
# E.g. fnord.logfile.format=3DLTM
#       STATUS | 2005/11/16 11:00:25 | --> FNORD Started as Console
#=09STATUS | 2005/11/16 11:00:25 | Launching a JVM...
#*********************************************************************
fnord.logfile.format=3DLTM

#*********************************************************************
# Log level for console output.  Valid log levels include:
#       NONE for no output,
#       FATAL to only show fatal error messages,
#       ERROR to show all error messages,
#       STATUS to show all state changes (the default),
#       INFO to show all JVM output and informative messages, and
#       DEBUG to show detailed debug information.
#*********************************************************************
fnord.logfile.loglevel=3DDEBUG

#*********************************************************************
# Maximum size that the log file will be allowed to grow to before the log
# is rolled.  Size is specified in bytes may be abbreviated with the 'k' (k=
b)
# or 'm' (mb) suffix.  The default value of 0 disables log rolling.
#*********************************************************************
fnord.logfile.maxsize=3D0

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

#*********************************************************************
# Log Level for sys/event log output; default is NONE.
# Valid loglevels are the same as the other loglevel related properties.
#*********************************************************************
fnord.syslog.loglevel=3DNONE

#*********************************************************************
# fnord.java.library.path.<n> --- Java library path to use.
#   Each element has a property name which starts with fnord.java.library.p=
ath.
#   and ends with a unique number between 1 and 40. The numbering
#   and ordering in the file need not be continuous, but avoid duplicates.
#*********************************************************************
fnord.java.library.path.1=3D/home/clvrmnky/servers/3817aix/server/lib
fnord.java.library.path.2=3D/home/clvrmnky/servers/3817aix/server/fnord/bin

#*********************************************************************
# Number of seconds to allow between pinging the JVM and obtaining the
# response. 0 means never time out.
#*********************************************************************
fnord.ping.timeout=3D300

#*********************************************************************
# Number of seconds to wait between startup attempts.
#*********************************************************************
fnord.restart.delay=3D60

#*********************************************************************
# Number of startup attempts to try before giving up.
#*********************************************************************
fnord.max_failed_invocations=3D20

#*********************************************************************
# Database Specific Properties
#*********************************************************************
# DB2
#fnord.java.library.path.3=3D%DB2DIR%/java12
#fnord.java.library.path.4=3D%DB2DIR%/java
#fnord.java.library.path.5=3D%DB2DIR%/bin
#fnord.java.library.path.6=3D%DB2DIR%/lib
#fnord.java.classpath.3=3D%DB2DIR%/java12/db2java.zip
#fnord.java.classpath.4=3D%DB2DIR%/java/db2java.zip

Re: [Wrapper-user] Config File Naming

[Tony S. <to...@ci...>]

Gets my vote too - would simplify my install scripts.

regards

Tony


> Oh yes, that would be perfect.
> We hacked the source here to add "fixed parameters" if none where given.
>
> A change like that would be just perfect.</repeat>
>
> Michael
>   
>> Does anyone else have a use for the feature where the name of the config file
>> maps to the name of the application?
>>
>> It allows two applications in the same directory without adding arguments to
>> the application and so is much cleaner.  For example,
>>
>> MyApp.exe looks for MyApp.conf
>> AnotherApp.exe looks for AnotherApp.conf
>>
>> etc.  It then looks for wrapper.conf if the app-specific wrapper does not
>> exist.
>>
>> We need to make this change to the lastest exe.  If it's of general interest,
>> I'll try and do it cleanly and create a diff.  Otherwise I'll just hack it in
>> there.
>>
>> Jim
>>
>>
>>     
>
>
>   

Re: [Wrapper-user] Config File Naming

[Michael 'b. S. <msc...@gi...>]

Oh yes, that would be perfect.
We hacked the source here to add "fixed parameters" if none where given.

A change like that would be just perfect.</repeat>

Michael

On Wed, 29 Mar 2006 - 6:49am, Jim Redman wrote:

> Does anyone else have a use for the feature where the name of the config file
> maps to the name of the application?
>
> It allows two applications in the same directory without adding arguments to
> the application and so is much cleaner.  For example,
>
> MyApp.exe looks for MyApp.conf
> AnotherApp.exe looks for AnotherApp.conf
>
> etc.  It then looks for wrapper.conf if the app-specific wrapper does not
> exist.
>
> We need to make this change to the lastest exe.  If it's of general interest,
> I'll try and do it cleanly and create a diff.  Otherwise I'll just hack it in
> there.
>
> Jim
>
>


-- 
  I love deadlines, especially the sound they make as they go whooshing by.

Re: [Wrapper-user] Wrapper error messages

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

Juergen,
I agree.  Your patch makes sense.  It will be in the next release.
I was only able to pach the unix version.  Windows has similar code
but there is not "app" variable or anything like it available.

Cheers,
Leif


Juergen Hermann wrote:
> Hi, Leif. The following code makes it hard to debug problems when you 
> get that error...
>
>     /* Get the full path and filename of this program */
>     if (realpath(app, szPath) == NULL) {
>         log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_FATAL, 
> 		"Unable to get the path-%s", getLastErrorText());
>         return 1;
>     }
>
> A better version would be:
>
>         log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_FATAL, 
> 		"Unable to get the path for '%s'-%s", app, getLastErrorText
> ());
>
> This might be true for other, similar error messages.
>
>
>
> Ciao, Jürgen
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>   

Re: [Wrapper-user] problem loading libwrapper.so

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

Xavier,
    That shouldn't be necessary.  The WrapperManager class will attempt 
to load
the libwrapper.so file using two names.  The first is the platform 
specific name,
in your case, libwrapper-linux-x86-32.so.  The second is the default 
libwrapper.so.
If the platform specific named file does not exist, it will fall back to 
the default name.
    This was done to make the delta-pack release possible.

    If you look at the debug output, you will see an error about the 
platform
named file not being found.  But the second libwrapper.so file should work
fine.  I can't imaging why on its won, adding the symbolic link would help
as it would still be attempting to load the original libwrapper.so file.

    What does that section of the debug wrapper.log file look like without
that symbolic link.  libwrapper-linux-x86-32.so should be failing to load.
But it should then continue on to attempt to load the libwrapper.so file.

    Cheers,
    Leif

Xavier Toth wrote:
> I ended up needing to do :
> ln -s libwrapper.so libwrapper-linux-x86-32.so
>
> is this mentioned anywhere in the docs?
>
> On 3/28/06, *Leif Mortenson* <le...@ta... 
> <mailto:le...@ta...>> wrote:
>
>     Xavier,
>         Can you set the wrapper.debug=true property and try this
>     again?  It
>     will show a little
>     more information about why the library could not be loaded.  You
>     may be
>     missing a
>     required system library or something.
>
>     Cheers,
>     Leif
>
>     Xavier Toth wrote:
>     > I'm running on Fedora Core 5 with SELinux in Permissive mode. I've
>     > verified that I have the 32 bit version and that the file is
>     owned by
>     > the user who my services run as. Is there something I'm missing
>     here?
>     >
>     >
>     > STATUS | wrapper  | 2006/03/28 15:06:10 | --> Wrapper Started as
>     Daemon
>     > STATUS | wrapper  | 2006/03/28 15:06:11 | Launching a JVM...
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 | Wrapper (Version 3.2.0)
>     > http://wrapper.tanukisoftware.org
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 | WARNING - Unable to
>     load the
>     > Wrapper's native library 'libwrapper.so'.
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           The file is
>     > located on the path at the following location but
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           could not be
>     loaded:
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |
>     > /opt/jwss/lib/libwrapper.so
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           Please
>     verify that
>     > the file is readable by the current user
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           and that the
>     file
>     > has not been corrupted in any way.
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           One common cause
>     > of this problem is running a 32-bit version
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           of the Wrapper
>     > with a 64-bit version of Java, or vica versa.
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           This is a
>     32-bit JVM.
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |           System signals
>     > will not be handled correctly.
>     > INFO   | jvm 1    | 2006/03/28 15:06:11 |
>     >
>
>

Re: [Wrapper-user] problem loading libwrapper.so

[Xavier T. <tx...@gm...>]

I ended up needing to do :
ln -s libwrapper.so libwrapper-linux-x86-32.so

is this mentioned anywhere in the docs?

On 3/28/06, Leif Mortenson <le...@ta...> wrote:
>
> Xavier,
>     Can you set the wrapper.debug=3Dtrue property and try this again?  It
> will show a little
> more information about why the library could not be loaded.  You may be
> missing a
> required system library or something.
>
> Cheers,
> Leif
>
> Xavier Toth wrote:
> > I'm running on Fedora Core 5 with SELinux in Permissive mode. I've
> > verified that I have the 32 bit version and that the file is owned by
> > the user who my services run as. Is there something I'm missing here?
> >
> >
> > STATUS | wrapper  | 2006/03/28 15:06:10 | --> Wrapper Started as Daemon
> > STATUS | wrapper  | 2006/03/28 15:06:11 | Launching a JVM...
> > INFO   | jvm 1    | 2006/03/28 15:06:11 | Wrapper (Version 3.2.0)
> > http://wrapper.tanukisoftware.org
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |
> > INFO   | jvm 1    | 2006/03/28 15:06:11 | WARNING - Unable to load the
> > Wrapper's native library 'libwrapper.so'.
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           The file is
> > located on the path at the following location but
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           could not be loaded=
:
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |
> > /opt/jwss/lib/libwrapper.so
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           Please verify that
> > the file is readable by the current user
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           and that the file
> > has not been corrupted in any way.
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           One common cause
> > of this problem is running a 32-bit version
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           of the Wrapper
> > with a 64-bit version of Java, or vica versa.
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           This is a 32-bit
> JVM.
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |           System signals
> > will not be handled correctly.
> > INFO   | jvm 1    | 2006/03/28 15:06:11 |
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

RE: [Wrapper-user] Config File Naming

[Alex K. <al...@kr...>]

Jim,

Yes that would be very useful for us too.

Regards,

Alex Kritikos
my-Channels 

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Jim Redman
Sent: Wednesday, March 29, 2006 4:50 PM
To: wra...@li...
Subject: [Wrapper-user] Config File Naming

Does anyone else have a use for the feature where the name of the config
file maps to the name of the application?

It allows two applications in the same directory without adding arguments to
the application and so is much cleaner.  For example,

MyApp.exe looks for MyApp.conf
AnotherApp.exe looks for AnotherApp.conf

etc.  It then looks for wrapper.conf if the app-specific wrapper does not
exist.

We need to make this change to the lastest exe.  If it's of general
interest, I'll try and do it cleanly and create a diff.  Otherwise I'll just
hack it in there.

Jim

--
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] Config File Naming

[Jim R. <jr...@er...>]

Does anyone else have a use for the feature where the name of the config 
file maps to the name of the application?

It allows two applications in the same directory without adding 
arguments to the application and so is much cleaner.  For example,

MyApp.exe looks for MyApp.conf
AnotherApp.exe looks for AnotherApp.conf

etc.  It then looks for wrapper.conf if the app-specific wrapper does 
not exist.

We need to make this change to the lastest exe.  If it's of general 
interest, I'll try and do it cleanly and create a diff.  Otherwise I'll 
just hack it in there.

Jim

-- 
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com

[Wrapper-user] Wrapper 3.2.0 Delta Pack Release

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

Hello all,
I uploaded the delta-pack distributions for the 3.2.0 release today.
This distribution contains the binaries necessary to run on any of the
platforms supported by this release.
The naming structure used in the delta-pack makes it possible to
generate a single binary distribution of a user application which runs
anywhere.

It works by renaming the wrapper binary from "wrapper" to
"wrapper-linux-x86-32" and "libwrapper.so" to "libwrapper-linux-x86-32.so"
The same pattern can be followed for the files from any wrapper
distribution.
The sh scripts, bat files, and wrapper jar are all aware of this
naming structure, correctly loading the binaries appropriate for
the current platform.

Cheers,
Leif