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

Re: [Wrapper-user] centos5 - Can't make old wrapper daemon go away

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

Horace,
Changing the APP_NAME and other properties you mentioned should
not have caused any problems.  Most likely something else was
modified it the latest script version that resolved your problem.
Without the version you were using, it is hard to say what that would
have been.

Within the Java application, you can call
WrapperManager.isLaunchedAsService() to find out whether or not
the Wrapper is running as a service.

On UNIX, this flag is true if the wrapper is run as a daemon.

Hope that helps,
Cheers,
Leif

Horace Pinker wrote:
> leif,
>
> thank you for your ultra fast response :D
>
> i now use the svn version of your script.
>
> i turned out, that i made some changes that caused the problem:
>
> # Application
> APP_NAME="@server@"
> APP_LONG_NAME="@my server@"
> # Wrapper
> WRAPPER_CMD="./wrapper"
>
> now works perfectly, while
>
> # Application
> APP_NAME="server"
> APP_LONG_NAME="my server"
> # Wrapper
> WRAPPER_CMD="./wrapper"
>
> did not work.
>
> btw .... is there a way to find out if the application was started as 
> a nt service / linux daemon in contrast to console? currently i 
> specify '-server' as an parameter to the application but it would be 
> great to decide this without any parameter. i use the method 1 for 
> integration.
>
> last but not least: keep up the great work - wrapper is fantastic! :D
>
> cheers,
> horace
>
>
> ----- Original Message ----
> From: Leif Mortenson <le...@ta...>
> To: wra...@li...
> Sent: Friday, September 28, 2007 2:24:19 PM
> Subject: Re: [Wrapper-user] centos5 - Can't make old wrapper daemon go 
> away
>
> Horace,
> What version of the Wrapper are you using?  I was working with a
> customer up until a couple months ago working with CentOS and
> it was working perfectly.  That was using the latest script out of
> SVN though:
> http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in
>
> For some reason the value of $WRAPPER_CMD is not being found in
> the output of your ps command.
>
> Can you run this and then post the results:
>
> echo $WRAPPER_CMD
> echo `$PSEXE -ww -p $pid -o args`
>
> That should make the cause clear.
>
> Cheers,
> Leif
>
> Horace Pinker wrote:
> >
> > i ran into a simliar problem like mark leone some months ago:
> > 
> http://www.nabble.com/Can%27t-make-old-wrapper-daemon-go-away-tf3346234.html#a9353225.
> >
> > however, i run the script on a fresh centos5 installation. but just to
> > be sure i added the -ww in my script, too.
> >
> > actually i found that the getpid() function always leads to a deletion
> > of the pid file, so i can not use the script to stop/status/restart a
> > service.
> >
> > i put in some echo statements to narrow the problem.
> >
> > have a look at this code:
> >
> > ...
> >                pidtest=`$PSEXE -ww -p $pid -o args | grep
> > "$WRAPPER_CMD" | tail -1`
> > echo "1"
> >                 echo `$PSEXE -ww -p $pid -o args`
> > echo "2"
> >                 echo `$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CMD"`
> > echo "3"
> >                 echo `$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CMD"
> > | tail -1`
> > echo "4"
> >         echo "$pidtest"
> > echo "4"
> > ....
> >
> > only between 1 and 2 there will be any output. in the moment the
> > result of ps is piped to the grep command there is no longer any
> > output. so especially $pidtest ist empty which leads to a deletion of
> > the pid file and so the script does not work at all.
> >
> > any thoughts?

Re: [Wrapper-user] centos5 - Can't make old wrapper daemon go away

[Horace P. <fli...@ya...>]

leif,=0A=0Athank you for your ultra fast response :D=0A=0Ai now use the svn=
 version of your script.=0A=0Ai turned out, that i made some changes that c=
aused the problem:=0A=0A# Application=0AAPP_NAME=3D"@server@"=0AAPP_LONG_NA=
ME=3D"@my server@"=0A# Wrapper=0AWRAPPER_CMD=3D"./wrapper"=0A=0Anow works p=
erfectly, while=0A=0A# Application=0A=0AAPP_NAME=3D"server"=0A=0AAPP_LONG_N=
AME=3D"my server"=0A=0A# Wrapper=0A=0AWRAPPER_CMD=3D"./wrapper"=0A=0A=0Adid=
 not work.=0A=0Abtw .... is there a way to find out if the application was =
started as a nt service / linux daemon in contrast to console? currently i =
specify '-server' as an parameter to the application but it would be great =
to decide this without any parameter. i use the method 1 for integration.=
=0A=0Alast but not least: keep up the great work - wrapper is fantastic! :D=
=0A=0Acheers,=0Ahorace=0A=0A=0A----- Original Message ----=0AFrom: Leif Mor=
tenson <le...@ta...>=0ATo: wra...@li...=
=0ASent: Friday, September 28, 2007 2:24:19 PM=0ASubject: Re: [Wrapper-user=
] centos5 - Can't make old wrapper daemon go away=0A=0AHorace,=0AWhat versi=
on of the Wrapper are you using?  I was working with a=0Acustomer up until =
a couple months ago working with CentOS and=0Ait was working perfectly.  Th=
at was using the latest script out of=0ASVN though:=0Ahttp://wrapper.svn.so=
urceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in=
=0A=0AFor some reason the value of $WRAPPER_CMD is not being found in=0Athe=
 output of your ps command.=0A=0ACan you run this and then post the results=
:=0A=0Aecho $WRAPPER_CMD=0Aecho `$PSEXE -ww -p $pid -o args`=0A=0AThat shou=
ld make the cause clear.=0A=0ACheers,=0ALeif=0A=0AHorace Pinker wrote:=0A>=
=0A> i ran into a simliar problem like mark leone some months ago: =0A> htt=
p://www.nabble.com/Can%27t-make-old-wrapper-daemon-go-away-tf3346234.html#a=
9353225.=0A>=0A> however, i run the script on a fresh centos5 installation.=
 but just to =0A> be sure i added the -ww in my script, too.=0A>=0A> actual=
ly i found that the getpid() function always leads to a deletion =0A> of th=
e pid file, so i can not use the script to stop/status/restart a =0A> servi=
ce.=0A>=0A> i put in some echo statements to narrow the problem.=0A>=0A> ha=
ve a look at this code:=0A>=0A> ...=0A>                pidtest=3D`$PSEXE -w=
w -p $pid -o args | grep =0A> "$WRAPPER_CMD" | tail -1`=0A> echo "1"=0A>   =
              echo `$PSEXE -ww -p $pid -o args`=0A> echo "2"=0A>           =
      echo `$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CMD"`=0A> echo "3"=
=0A>                 echo `$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CMD"=
 =0A> | tail -1`=0A> echo "4"=0A>         echo "$pidtest"=0A> echo "4"=0A> =
....=0A>=0A> only between 1 and 2 there will be any output. in the moment t=
he =0A> result of ps is piped to the grep command there is no longer any =
=0A> output. so especially $pidtest ist empty which leads to a deletion of =
=0A> the pid file and so the script does not work at all.=0A>=0A> any thoug=
hts?=0A=0A=0A--------------------------------------------------------------=
-----------=0AThis SF.net email is sponsored by: Microsoft=0ADefy all chall=
enges. Microsoft(R) Visual Studio 2005.=0Ahttp://clk.atdmt.com/MRT/go/vse01=
20000070mrt/direct/01/=0A_______________________________________________=0A=
Wrapper-user mailing lis...@li...=0Ahttps://li=
sts.sourceforge.net/lists/listinfo/wrapper-user=0A=0A=0A=0A=0A=0A=0A=0A    =
   =0A_____________________________________________________________________=
_______________=0ALooking for a deal? Find great prices on flights and hote=
ls with Yahoo! FareChase.=0Ahttp://farechase.yahoo.com/

Re: [Wrapper-user] centos5 - Can't make old wrapper daemon go away

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

Horace,
What version of the Wrapper are you using?  I was working with a
customer up until a couple months ago working with CentOS and
it was working perfectly.  That was using the latest script out of
SVN though:
http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in

For some reason the value of $WRAPPER_CMD is not being found in
the output of your ps command.

Can you run this and then post the results:

echo $WRAPPER_CMD
echo `$PSEXE -ww -p $pid -o args`

That should make the cause clear.

Cheers,
Leif

Horace Pinker wrote:
>
> i ran into a simliar problem like mark leone some months ago: 
> http://www.nabble.com/Can%27t-make-old-wrapper-daemon-go-away-tf3346234.html#a9353225.
>
> however, i run the script on a fresh centos5 installation. but just to 
> be sure i added the -ww in my script, too.
>
> actually i found that the getpid() function always leads to a deletion 
> of the pid file, so i can not use the script to stop/status/restart a 
> service.
>
> i put in some echo statements to narrow the problem.
>
> have a look at this code:
>
> ...
>                pidtest=`$PSEXE -ww -p $pid -o args | grep 
> "$WRAPPER_CMD" | tail -1`
> echo "1"
>                 echo `$PSEXE -ww -p $pid -o args`
> echo "2"
>                 echo `$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CMD"`
> echo "3"
>                 echo `$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CMD" 
> | tail -1`
> echo "4"
>         echo "$pidtest"
> echo "4"
> ....
>
> only between 1 and 2 there will be any output. in the moment the 
> result of ps is piped to the grep command there is no longer any 
> output. so especially $pidtest ist empty which leads to a deletion of 
> the pid file and so the script does not work at all.
>
> any thoughts?

[Wrapper-user] centos5 - Can't make old wrapper daemon go away

[Horace P. <fli...@ya...>]

=0Ai ran into a simliar problem like mark leone some months ago: http://www=
.nabble.com/Can%27t-make-old-wrapper-daemon-go-away-tf3346234.html#a9353225=
.=0A=0Ahowever, i run the script on a fresh centos5 installation. but just =
to be sure i added the -ww in my script, too.=0A=0Aactually i found that th=
e getpid() function always leads to a deletion of the pid file, so i can no=
t use the script to stop/status/restart a service.=0A=0Ai put in some echo =
statements to narrow the problem.=0A=0Ahave a look at this code:=0A=0A...=
=0A               pidtest=3D`$PSEXE -ww -p $pid -o args | grep "$WRAPPER_CM=
D" | tail -1`=0Aecho "1"=0A                echo `$PSEXE -ww -p $pid -o args=
`=0Aecho "2"=0A                echo `$PSEXE -ww -p $pid -o args | grep "$WR=
APPER_CMD"`=0Aecho "3"=0A                echo `$PSEXE -ww -p $pid -o args |=
 grep "$WRAPPER_CMD" | tail -1`=0Aecho "4"=0A        echo "$pidtest"=0Aecho=
 "4"=0A=0A....=0A=0Aonly between 1 and 2 there will be any output. in the m=
oment the result of ps is piped to the grep command there is no longer any =
output. so especially $pidtest ist empty which leads to a deletion of the p=
id file and so the script does not work at all.=0A=0Aany thoughts?=0A=0A=0A=
=0A=0A=0A       =0A________________________________________________________=
____________________________=0ATake the Internet to Go: Yahoo!Go puts the I=
nternet in your pocket: mail, news, photos & more. =0Ahttp://mobile.yahoo.c=
om/go?refer=3D1GNXIC

Re: [Wrapper-user] JVM exited in response to signal UNKNOWN (127)

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

Amresh,
As long as you use the wrapper's shell script to control the wrapper
the user will see no difference in the way the shell script works.
The shell script uses a pid file regardless, but yes, it does also start
using an anchor file to control the shutdown.  That is how the script
communicates with the wrapper process.

The Wrapper communicates with the JVM using a backend socket
regardless of whether or not ignore signals is set.

Cheers,
Leif

Amresh Deshmukh wrote:
> Thanks for your reply Leif.
>
> I will try the wrapper.debug setting.
>
> We see the problem occuring more on one of our servers. It is not reproducible (predictably) though.
>
> Will also make sure that we have upgraded the sh script.
>
> With regards to IGNORE_SIGNALS I thought using that would mean we will have to start uising an anchor file for stopping the JVM. Is that right?
>
> I will update you with what I find.
>
> Regards,
>
> Amresh
>
>
>
>
>
>
> ----- Original Message ----
> From: Leif Mortenson <le...@ta...>
> To: wra...@li...
> Sent: Friday, September 28, 2007 7:58:52 AM
> Subject: Re: [Wrapper-user] JVM exited in response to signal UNKNOWN (127)
>
>
> Amresh,
> What platform is this running on?   I had a problem at a customer
> several years ago on Solaris where the Wrapper would sometimes
> receive TERM signals from someplace.  The solution was to add a
> feature to ignore all system signals.   That works for all signals
> except for the SIGKILL.  Which it appears you are receiving.
>
> How easy is this for you to reproduce?  If you set
> wrapper.debug=true then the Wrapper will add log data about
> which process sent the signals.  That might be useful to track
> down where the stray signals are coming from.
>
> In the case of my old customer, it was another user application
> which was using old PIDs to try clean up its own process instances.
>
> To enable the ignore singals feature simple edit the wrapper's
> shell script uncomment the following line:
> #IGNORE_SIGNALS=true
>
> As you upgraded the Wrapper, make sure that you are also
> upgrading the shell script.
>
> Let me know how this works out.
> Cheers,
> Leif
>
>
> Amresh Deshmukh wrote:
>   
>> We have been using wrapper for last few years.
>>
>> We were using version 3.1.2 of the wrapper and have recently upgraded to the latest version 3.2.3.
>>
>> The reason for upgrade was the error:
>>
>> "Critical error: wait for JVM process failed (No child processes)" 
>>
>> Which as I found was fixed in version 3.2.0.
>>
>> After the upgrade we have seen occurence of the following error in our log files. 
>>
>> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response to signal UNKNOWN (127).
>> ERROR | wrapper | 2007/09/27 15:32:51 | JVM exited unexpectedly.
>> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response to signal SIGKILL (9).
>> ERROR | wrapper | 2007/09/27 15:32:51 | Unable to start a JVM
>> STATUS | wrapper | 2007/09/27 15:32:51 | <-- Wrapper Stopped
>>
>> We have put in a fix today for the "Unable to start a JVM" using the suggestion in one of the posts.
>>
>> wrapper.on_exit.default=RESTART
>> wrapper.on_exit.0=SHUTDOWN
>>
>> We have also increased the restart delay to 30 seconds.
>>
>> wrapper.restart.delay=30
>>
>> The problem now is the fact that the JVM restart results in loss of cached data which impacts performance at the time of batch processing.
>>
>>
>> We are running on 64 bit Linux OS with 32 bit jdk1.5.0_12 JVM (32 bit limitation due a third party library)
>> OS details: 
>> Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
>> Linux 2.4.21-32.0.1.ELsmp #1 SMP EDT x86_64
>>
>> It would be very helpful to know under what circumstances we could get an error like this. We are in last week of UAT due to go live next week any resolution/workaround for this would be highly appreciated.
>>
>>
>> Amresh
>>   
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>        
> ____________________________________________________________________________________
> Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
> http://answers.yahoo.com/dir/?link=list&sid=396545433
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>   

Re: [Wrapper-user] JVM exited in response to signal UNKNOWN (127)

[Amresh D. <amr...@ya...>]

Thanks for your reply Leif.=0A=0AI will try the wrapper.debug setting.=0A=
=0AWe see the problem occuring more on one of our servers. It is not reprod=
ucible (predictably) though.=0A=0AWill also make sure that we have upgraded=
 the sh script.=0A=0AWith regards to IGNORE_SIGNALS I thought using that wo=
uld mean we will have to start uising an anchor file for stopping the JVM. =
Is that right?=0A=0AI will update you with what I find.=0A=0ARegards,=0A=0A=
Amresh=0A=0A=0A=0A=0A=0A=0A----- Original Message ----=0AFrom: Leif Mortens=
on <le...@ta...>=0ATo: wra...@li...=0ASen=
t: Friday, September 28, 2007 7:58:52 AM=0ASubject: Re: [Wrapper-user] JVM =
exited in response to signal UNKNOWN (127)=0A=0A=0AAmresh,=0AWhat platform =
is this running on?   I had a problem at a customer=0Aseveral years ago on =
Solaris where the Wrapper would sometimes=0Areceive TERM signals from somep=
lace.  The solution was to add a=0Afeature to ignore all system signals.   =
That works for all signals=0Aexcept for the SIGKILL.  Which it appears you =
are receiving.=0A=0AHow easy is this for you to reproduce?  If you set=0Awr=
apper.debug=3Dtrue then the Wrapper will add log data about=0Awhich process=
 sent the signals.  That might be useful to track=0Adown where the stray si=
gnals are coming from.=0A=0AIn the case of my old customer, it was another =
user application=0Awhich was using old PIDs to try clean up its own process=
 instances.=0A=0ATo enable the ignore singals feature simple edit the wrapp=
er's=0Ashell script uncomment the following line:=0A#IGNORE_SIGNALS=3Dtrue=
=0A=0AAs you upgraded the Wrapper, make sure that you are also=0Aupgrading =
the shell script.=0A=0ALet me know how this works out.=0ACheers,=0ALeif=0A=
=0A=0AAmresh Deshmukh wrote:=0A> We have been using wrapper for last few ye=
ars.=0A>=0A> We were using version 3.1.2 of the wrapper and have recently u=
pgraded to the latest version 3.2.3.=0A>=0A> The reason for upgrade was the=
 error:=0A>=0A> "Critical error: wait for JVM process failed (No child proc=
esses)" =0A>=0A> Which as I found was fixed in version 3.2.0.=0A>=0A> After=
 the upgrade we have seen occurence of the following error in our log files=
. =0A>=0A> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response =
to signal UNKNOWN (127).=0A> ERROR | wrapper | 2007/09/27 15:32:51 | JVM ex=
ited unexpectedly.=0A> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited =
in response to signal SIGKILL (9).=0A> ERROR | wrapper | 2007/09/27 15:32:5=
1 | Unable to start a JVM=0A> STATUS | wrapper | 2007/09/27 15:32:51 | <-- =
Wrapper Stopped=0A>=0A> We have put in a fix today for the "Unable to start=
 a JVM" using the suggestion in one of the posts.=0A>=0A> wrapper.on_exit.d=
efault=3DRESTART=0A> wrapper.on_exit.0=3DSHUTDOWN=0A>=0A> We have also incr=
eased the restart delay to 30 seconds.=0A>=0A> wrapper.restart.delay=3D30=
=0A>=0A> The problem now is the fact that the JVM restart results in loss o=
f cached data which impacts performance at the time of batch processing.=0A=
>=0A>=0A> We are running on 64 bit Linux OS with 32 bit jdk1.5.0_12 JVM (32=
 bit limitation due a third party library)=0A> OS details: =0A> Red Hat Ent=
erprise Linux AS release 3 (Taroon Update 5)=0A> Linux 2.4.21-32.0.1.ELsmp =
#1 SMP EDT x86_64=0A>=0A> It would be very helpful to know under what circu=
mstances we could get an error like this. We are in last week of UAT due to=
 go live next week any resolution/workaround for this would be highly appre=
ciated.=0A>=0A>=0A> Amresh=0A>   =0A=0A=0A---------------------------------=
----------------------------------------=0AThis SF.net email is sponsored b=
y: Microsoft=0ADefy all challenges. Microsoft(R) Visual Studio 2005.=0Ahttp=
://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=0A_____________________=
__________________________=0AWrapper-user mailing list=0AWrapper-user@lists=
.sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/wrapper-use=
r=0A=0A=0A       =0A_______________________________________________________=
_____________________________=0ABe a better Heartthrob. Get better relation=
ship answers from someone who knows. Yahoo! Answers - Check it out. =0Ahttp=
://answers.yahoo.com/dir/?link=3Dlist&sid=3D396545433

Re: [Wrapper-user] JVM exited in response to signal UNKNOWN (127)

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

Amresh,
What platform is this running on?   I had a problem at a customer
several years ago on Solaris where the Wrapper would sometimes
receive TERM signals from someplace.  The solution was to add a
feature to ignore all system signals.   That works for all signals
except for the SIGKILL.  Which it appears you are receiving.

How easy is this for you to reproduce?  If you set
wrapper.debug=true then the Wrapper will add log data about
which process sent the signals.  That might be useful to track
down where the stray signals are coming from.

In the case of my old customer, it was another user application
which was using old PIDs to try clean up its own process instances.

To enable the ignore singals feature simple edit the wrapper's
shell script uncomment the following line:
#IGNORE_SIGNALS=true

As you upgraded the Wrapper, make sure that you are also
upgrading the shell script.

Let me know how this works out.
Cheers,
Leif
 

Amresh Deshmukh wrote:
> We have been using wrapper for last few years.
>
> We were using version 3.1.2 of the wrapper and have recently upgraded to the latest version 3.2.3.
>
> The reason for upgrade was the error:
>
> "Critical error: wait for JVM process failed (No child processes)" 
>
> Which as I found was fixed in version 3.2.0.
>
> After the upgrade we have seen occurence of the following error in our log files. 
>
> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response to signal UNKNOWN (127).
> ERROR | wrapper | 2007/09/27 15:32:51 | JVM exited unexpectedly.
> STATUS | wrapper | 2007/09/27 15:32:51 | JVM exited in response to signal SIGKILL (9).
> ERROR | wrapper | 2007/09/27 15:32:51 | Unable to start a JVM
> STATUS | wrapper | 2007/09/27 15:32:51 | <-- Wrapper Stopped
>
> We have put in a fix today for the "Unable to start a JVM" using the suggestion in one of the posts.
>
> wrapper.on_exit.default=RESTART
> wrapper.on_exit.0=SHUTDOWN
>
> We have also increased the restart delay to 30 seconds.
>
> wrapper.restart.delay=30
>
> The problem now is the fact that the JVM restart results in loss of cached data which impacts performance at the time of batch processing.
>
>
> We are running on 64 bit Linux OS with 32 bit jdk1.5.0_12 JVM (32 bit limitation due a third party library)
> OS details: 
> Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
> Linux 2.4.21-32.0.1.ELsmp #1 SMP EDT x86_64
>
> It would be very helpful to know under what circumstances we could get an error like this. We are in last week of UAT due to go live next week any resolution/workaround for this would be highly appreciated.
>
>
> Amresh
>   

[Wrapper-user] JVM exited in response to signal UNKNOWN (127)

[Amresh D. <amr...@ya...>]

We have been using wrapper for last few years.=0A=0AWe were using version 3=
.1.2 of the wrapper and have recently upgraded to the latest version 3.2.3.=
=0A=0AThe reason for upgrade was the error:=0A=0A"Critical error: wait for =
JVM process failed (No child processes)" =0A=0AWhich as I found was fixed i=
n version 3.2.0.=0A=0AAfter the upgrade we have seen occurence of the follo=
wing error in our log files. =0A=0ASTATUS | wrapper | 2007/09/27 15:32:51 |=
 JVM exited in response to signal UNKNOWN (127).=0AERROR | wrapper | 2007/0=
9/27 15:32:51 | JVM exited unexpectedly.=0ASTATUS | wrapper | 2007/09/27 15=
:32:51 | JVM exited in response to signal SIGKILL (9).=0AERROR | wrapper | =
2007/09/27 15:32:51 | Unable to start a JVM=0ASTATUS | wrapper | 2007/09/27=
 15:32:51 | <-- Wrapper Stopped=0A=0AWe have put in a fix today for the "Un=
able to start a JVM" using the suggestion in one of the posts.=0A=0Awrapper=
.on_exit.default=3DRESTART=0Awrapper.on_exit.0=3DSHUTDOWN=0A=0AWe have also=
 increased the restart delay to 30 seconds.=0A=0Awrapper.restart.delay=3D30=
=0A=0AThe problem now is the fact that the JVM restart results in loss of c=
ached data which impacts performance at the time of batch processing.=0A=0A=
=0AWe are running on 64 bit Linux OS with 32 bit jdk1.5.0_12 JVM (32 bit li=
mitation due a third party library)=0AOS details: =0ARed Hat Enterprise Lin=
ux AS release 3 (Taroon Update 5)=0ALinux 2.4.21-32.0.1.ELsmp #1 SMP EDT x8=
6_64=0A=0AIt would be very helpful to know under what circumstances we coul=
d get an error like this. We are in last week of UAT due to go live next we=
ek any resolution/workaround for this would be highly appreciated.=0A=0A=0A=
Amresh=0A=0A=0A      ______________________________________________________=
______________________________=0AFussy? Opinionated? Impossible to please? =
Perfect.  Join Yahoo!'s user panel and lay it on us. http://surveylink.yaho=
o.com/gmrs/yahoo_panel_invite.asp?a=3D7=0A=0A=0A      _____________________=
_______________________________________________________________=0ATonight's=
 top picks. What will you watch tonight? Preview the hottest shows on Yahoo=
! TV.=0Ahttp://tv.yahoo.com/ =0A

Re: [Wrapper-user] 64-bit Build Error on Win64

[Tim W. <Tim...@or...>]

T25lIG9mIHlvdXIgb2JqZWN0IGZpbGVzIGhhcyBiZWVuIGNvbXBpbGVkIHdpdGggdGhlIC9NQUNI
SU5FOng4NiBmbGFnLg0KRG91YmxlIGNoZWNrIHlvdSd2ZSB1cGRhdGVkIGFsbCB0aGUgL01BQ0hJ
TkUgZmxhZ3MsIGFuZCBkbyBhIGNsZWFuL3JlYnVpbGQuDQoNCnRpbQ0KDQogIA0KDQpUaW0gV2hp
dHRpbmd0b24NCkRldmVsb3BtZW50IFVuaXQgTWFuYWdlciAtIENvbmNlcnRvIFBvcnRhbA0KVGlt
LldoaXR0aW5ndG9uQG9yaW9uaGVhbHRoLmNvbQ0KUDogKzY0IDkgNjM4IDA2MDAgeDM4NzMNCk06
ICs2NCAyMSAzMDcgOTI1IA0KRjogKzY0IDkgNjM4IDA2OTkNClM6IHRpbS53aGl0dGluZ3Rvbg0K
d3d3Lm9yaW9uaGVhbHRoLmNvbSANCg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz
IGFyZSBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIHRvIHdob20gaXQgaXMgYWRkcmVzc2Vk
IGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXIgZGF0YSBw
cm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBJZiB5b3UgYXJl
IG5vdCB0aGUgYWRkcmVzc2VlIG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJp
bmcgdGhpcyB0byB0aGUgYWRkcmVzc2VlIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgcmVh
ZGluZywgY29weWluZyBvciBkaXN0cmlidXRpbmcgdGhpcyB0cmFuc21pc3Npb24gaXMgcHJvaGli
aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSB0
ZWxlcGhvbmUgdXMgaW1tZWRpYXRlbHkgYW5kIHJlbW92ZSBhbGwgY29waWVzIG9mIGl0IGZyb20g
eW91ciBzeXN0ZW0uIFRoYW5rIHlvdSBmb3IgeW91ciBjby1vcGVyYXRpb24uDQoNCg0KPj4+IE9u
IEZyaSwgU2VwIDI4LCAyMDA3IGF0ICA0OjIwIGEubS4sIGluIG1lc3NhZ2UgPDA0MEYyOUEwNDA2
Mzg4NDZBOUIwRTQ4RDZEMjE0QjNDMDI2NUFCRkVERUBleGNoMms3LmhxLmJyb2Nhc3lzdGVtcy5j
b20+LCAiVG9tIFNhdWxwYXVnaCIgPFRvbS5TYXVscGF1Z2hATWV0YUxJTkNTLmNvbT4gd3JvdGU6
DQoNCkknbSBmb2xsb3dpbmcgaW5zdHJ1Y3Rpb25zIGZyb20gTWF0dGlhcyBvbiBob3cgdG8gYnVp
bGQgNjQtYml0IHdyYXBwZXIgb24gV2luNjQuDQogDQoxKSBDaGVja291dCBmcm9tIFNWTiB0cnVj
ay4NCjIpIENvcHkgTWFrZWZpbGUtd2luZG93cy14ODYtMzIubm1ha2UgdG8gTWFrZWZpbGUtd2lu
ZG93cy14ODYtNjQubm1ha2UNCihsb2NhdGVkIGluIC4uXHNyY1xjXCkNCjMpIEVkaXRlZCBNYWtl
ZmlsZS13aW5kb3dzLXg4Ni02NC5ubWFrZQ0KICAgMy4xKSBSZW1vdmUgLVpwNCBmcm9tIGNvbXBp
bGUgb3B0aW9ucyAoc2VhbXMgdG8gY2F1c2UgJ1N0ZG91dCBwaXBlDQpjcmVhdGlvbiBmYWlsZWQn
ID8hKQ0KICAgMy4yKSBDaGFuZ2VkIC9NQUNISU5FOlg4NiB0byAvTUFDSElORTpYNjQNCiAgIDMu
MykgRVhFX09VVERJUiA9ICQoUFJPSikzMl9WQzhfX1dpbjMyX1JlbGVhc2UgdG8gRVhFX09VVERJ
UiA9DQokKFBST0opMzJfVkM4X19XaW42NF9SZWxlYXNlDQogICAzLjQpIERMTF9PVVRESVIgPSAk
KFBST0opSk5JMzJfVkM4X19XaW4zMl9SZWxlYXNlIHRvIERMTF9PVVRESVIgPQ0KJChQUk9KKUpO
STMyX1ZDOF9fV2luNjRfUmVsZWFzZQ0KIA0KNCkgT3BlbiBhIFZpc3VhbCBTdHVkaW8gMjAwNSB4
NjQgY29tbWFuZCBwcm9tcHQgKGFuZCBJIHVzZSBqYXZhIDEuNi4wXzAyDQo2NC1iaXQgU2VydmVy
KQ0KICAgNC4xKSBhbnQgLURiaXRzPTY0DQogDQpSZWdhcmRzLA0KICAgL01hdHRpYXMNCiANClRo
aXMgd29ya2VkIGZvciBtZSB0aGUgZmlyc3QgdGltZSBJIGJ1aWx0LCBidXQgbm93IEkgZ2V0IHRo
aXMgZXJyb3IgZnJvbSB0aGUgbGlua2VyOg0KIA0KICAgICBbZXhlY10gICAgIGxpbmsgL05PTE9H
TyAvTUFOSUZFU1QgL0RFQlVHIC9NQUNISU5FOlg2NCAvRVJST1JSRVBPUlQ6UFJPTVBUIEQNCmVs
YXlJbXAubGliIC9JTkNSRU1FTlRBTDpOTyAvU1VCU1lTVEVNOkNPTlNPTEUgL01BTklGRVNURklM
RToid3JhcHBlcjMyX1ZDOF9fV2luDQo2NF9SZWxlYXNlXHdyYXBwZXIuZXhlLmludGVybWVkaWF0
ZS5tYW5pZmVzdCIgL1BEQjoid3JhcHBlcjMyX1ZDOF9fV2luNjRfUmVsZWFzZQ0KXHdyYXBwZXIu
cGRiIiAvT1BUOlJFRiAvT1BUOklDRiAvT1BUOldJTjk4IC9MVENHIHdyYXBwZXIzMl9WQzhfX1dp
bjY0X1JlbGVhc2VcbG8NCmdnZXIub2JqIHdyYXBwZXIzMl9WQzhfX1dpbjY0X1JlbGVhc2VccHJv
cGVydHkub2JqIHdyYXBwZXIzMl9WQzhfX1dpbjY0X1JlbGVhc2VcDQp3cmFwcGVyLm9iaiB3cmFw
cGVyMzJfVkM4X19XaW42NF9SZWxlYXNlXHdyYXBwZXJfd2luLm9iaiB3cmFwcGVyMzJfVkM4X19X
aW42NF9SZQ0KbGVhc2Vcd3JhcHBlcmV2ZW50bG9vcC5vYmogd3JhcHBlcjMyX1ZDOF9fV2luNjRf
UmVsZWFzZVx3cmFwcGVyaW5mby5vYmogd3NvY2szMi4NCmxpYiBzaGx3YXBpLmxpYiBhZHZhcGkz
Mi5saWIgdXNlcjMyLmxpYiB3cmFwcGVyMzJfVkM4X19XaW42NF9SZWxlYXNlXHdyYXBwZXIucmVz
DQogL09VVDoiLi5cLi5cYmluXHdyYXBwZXIuZXhlIg0KICAgICBbZXhlY10gd3JhcHBlcjMyX1ZD
OF9fV2luNjRfUmVsZWFzZVxsb2dnZXIub2JqIDogZmF0YWwgZXJyb3IgTE5LMTExMjogbW9kdWwN
CmUgbWFjaGluZSB0eXBlICdYODYnIGNvbmZsaWN0cyB3aXRoIHRhcmdldCBtYWNoaW5lIHR5cGUg
J3g2NCcNCiANCkkgdGhpbmsgc29tZXRoaW5nIGluIG15IFZpc3VhbCBTdHVkaW8gMjAwNSBlbnZp
cm9ubWVudCBoYXMgY2hhbmdlZC4NCiANCkhhcyBhbnlvbmUgc2VlbiB0aGlzPw0KIA0KVGhhbmtz
LA0KIA0KVG9tDQogDQogDQpOb3RpY2U6IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p
dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl
IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXIgYW5kIGRlc3Ryb3kgYW55IGNvcGllcyBvZiB0aGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVu
dHMuIFlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVuYXV0aG9yaXplZCByZXZpZXcs
IHVzZSwgZGlzY2xvc3VyZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBjb3B5aW5n
IG9mIHRoaXMgY29tbXVuaWNhdGlvbiwgb3IgYW55IG9mIGl0cyBjb250ZW50cywgaXMgc3RyaWN0
bHkgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJl
c2VudGVkIGluIHRoaXMgZW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBk
byBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRob3NlIG9mIHRoZSBjb21wYW55LiBUaGUgcmVj
aXBpZW50IHNob3VsZCBjaGVjayB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgZm9yIHRo
ZSBwcmVzZW5jZSBvZiB2aXJ1c2VzLiBUaGUgY29tcGFueSBhY2NlcHRzIG5vIGxpYWJpbGl0eSBm
b3IgYW55IGRhbWFnZSBjYXVzZWQgYnkgYW55IHZpcnVzIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1h
aWwuIA==

[Wrapper-user] 64-bit Build Error on Win64

[Tom S. <Tom...@Me...>]

I'm following instructions from Mattias on how to build 64-bit wrapper =
on Win64.


1) Checkout from SVN truck.

2) Copy Makefile-windows-x86-32.nmake to Makefile-windows-x86-64.nmake

(located in ..\src\c\)

3) Edited Makefile-windows-x86-64.nmake

   3.1) Remove -Zp4 from compile options (seams to cause 'Stdout pipe

creation failed' ?!)

   3.2) Changed /MACHINE:X86 to /MACHINE:X64

   3.3) EXE_OUTDIR =3D $(PROJ)32_VC8__Win32_Release to EXE_OUTDIR =3D

$(PROJ)32_VC8__Win64_Release

   3.4) DLL_OUTDIR =3D $(PROJ)JNI32_VC8__Win32_Release to DLL_OUTDIR =3D

$(PROJ)JNI32_VC8__Win64_Release



4) Open a Visual Studio 2005 x64 command prompt (and I use java 1.6.0_02

64-bit Server)

   4.1) ant -Dbits=3D64



Regards,
   /Mattias

This worked for me the first time I built, but now I get this error from =
the linker:

     [exec]     link /NOLOGO /MANIFEST /DEBUG /MACHINE:X64 =
/ERRORREPORT:PROMPT D
elayImp.lib /INCREMENTAL:NO /SUBSYSTEM:CONSOLE =
/MANIFESTFILE:"wrapper32_VC8__Win
64_Release\wrapper.exe.intermediate.manifest" =
/PDB:"wrapper32_VC8__Win64_Release
\wrapper.pdb" /OPT:REF /OPT:ICF /OPT:WIN98 /LTCG =
wrapper32_VC8__Win64_Release\lo
gger.obj wrapper32_VC8__Win64_Release\property.obj =
wrapper32_VC8__Win64_Release\
wrapper.obj wrapper32_VC8__Win64_Release\wrapper_win.obj =
wrapper32_VC8__Win64_Re
lease\wrappereventloop.obj wrapper32_VC8__Win64_Release\wrapperinfo.obj =
wsock32.
lib shlwapi.lib advapi32.lib user32.lib =
wrapper32_VC8__Win64_Release\wrapper.res
 /OUT:"..\..\bin\wrapper.exe"
     [exec] wrapper32_VC8__Win64_Release\logger.obj : fatal error =
LNK1112: modul
e machine type 'X86' conflicts with target machine type 'x64'

I think something in my Visual Studio 2005 environment has changed.

Has anyone seen this?

Thanks,

Tom


--
Notice: This email and any files transmitted with it are confidential =
and intended solely for the individual or entity to which they are =
addressed.  If you have received this email in error please notify the =
sender and destroy any copies of this email and its attachments.  You =
are hereby notified that any unauthorized review, use, disclosure, =
dissemination, distribution, or copying of this communication, or any of =
its contents, is strictly prohibited.  Please note that any views or =
opinions presented in this email are solely those of the author and do =
not necessarily represent those of the company.  The recipient should =
check this email and any attachments for the presence of viruses.  The =
company accepts no liability for any damage caused by any virus =
transmitted by this email.

Re: [Wrapper-user] RES: Problems with wrapper and Windows

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

Juliana Jacques Leroy wrote:
> Where can I look for the version?
> Someone else put it to work and I don't know which version was used...
>   
You can get the version by running:
wrapper.exe -v
> How can I enable debug?
>   
In your wrapper.conf file, add the following property:
wrapper.deug=true

Cheers,
Leif
> -----Mensagem original-----
> De: Leif Mortenson [mailto:le...@ta...]
> Enviada em: quarta-feira, 26 de setembro de 2007 19:52
> Para: wra...@li...
> Assunto: Re: [Wrapper-user] Problems with wrapper and Windows [XW-SPAM -
> heur][XW-SPAM - mx]
>
>
> Juliana,
> What version of the Wrapper are you using?
>
> Is this something you are able to reproduce?  If so, try running it with
> wrapper.debug enabled.  Seeing more precisely where it crashed
> would give me something to go on.
>
> Leif
>
> Juliana Jacques Leroy wrote:
>   
>> Hi all,
>>
>> Sometimes the wrapper.exe is canceling with windows. I get this error in the EventViewer:
>>
>> -------------------------------------------------------------------------------------------------------------------------------------------------
>> Event Type: Information
>> Event Source: DrWatson
>> Event Category: None
>> Event ID: 4097
>> Date: 26/9/2007
>> Time: 14:36:00
>> User: N/A
>> Computer: SCX340242
>> Description:
>> The application, C:\SADSXP\TelnetDService\bin\wrapper.exe, generated an application error The error occurred on 09/26/2007 @ 14:35:58.041 The exception generated was c0000005 at address 0040E42A (wrapper)
>> -------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Any ideas?
>> I'm running Windows Server 2003 Enterprise Edition.
>>
>> Thanks,
>> Juliana.
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>   

[Wrapper-user] RES: Problems with wrapper and Windows

[Juliana J. L. <Ju...@ms...>]

Where can I look for the version?
Someone else put it to work and I don't know which version was used...

How can I enable debug?

Thanks,
Juliana.

-----Mensagem original-----
De: Leif Mortenson [mailto:le...@ta...]
Enviada em: quarta-feira, 26 de setembro de 2007 19:52
Para: wra...@li...
Assunto: Re: [Wrapper-user] Problems with wrapper and Windows [XW-SPAM -
heur][XW-SPAM - mx]


Juliana,
What version of the Wrapper are you using?

Is this something you are able to reproduce?  If so, try running it with
wrapper.debug enabled.  Seeing more precisely where it crashed
would give me something to go on.

Leif

Juliana Jacques Leroy wrote:
> Hi all,
>
> Sometimes the wrapper.exe is canceling with windows. I get this error =
in the EventViewer:
>
> =
-------------------------------------------------------------------------=
------------------------------------------------------------------------
> Event Type: Information
> Event Source: DrWatson
> Event Category: None
> Event ID: 4097
> Date: 26/9/2007
> Time: 14:36:00
> User: N/A
> Computer: SCX340242
> Description:
> The application, C:\SADSXP\TelnetDService\bin\wrapper.exe, generated =
an application error The error occurred on 09/26/2007 @ 14:35:58.041 The =
exception generated was c0000005 at address 0040E42A (wrapper)
> =
-------------------------------------------------------------------------=
------------------------------------------------------------------------
>
> Any ideas?
> I'm running Windows Server 2003 Enterprise Edition.
>
> Thanks,
> Juliana.


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] 4096MB heap limit

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

Tom,
The 4Gb limit is very historical. It went in long before 64 bit machines
were in the picture. This limit has been removed from the source for
the 3.3.0 release. (which is pending)

As mentioned, in 3.2.3, you cam work around this easily by doing the
following:
wrapper.java.additional.5=-Xms6000m
wrapper.java.additional.6=-Xmx6000m
wrapper.java.initmemory=0
wrapper.java.maxmemory=0

Setting the Wrapper's memory limits to 0 makes it possible to specify
them manually:
http://wrapper.tanukisoftware.org/doc/english/prop-java-maxmemory.html
http://wrapper.tanukisoftware.org/doc/english/prop-java-initmemory.html

Also set the following. It will let you see the generated java command
to verify that it is generating what you expect.
wrapper.java.command.loglevel=INFO

Cheers,
Leif

Chandra Patni wrote:
>
> Wrapper-3.2.3 64 bit for linux
>
> Make sure that you have not specified wrapper.java.initmemory and 
> wrapper.java.maxmemory.
>
> BTW, you’ve not specified the units of memory and the default unit is 
> byte.
>
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html
>
> ------------------------------------------------------------------------
>
> *From:* wra...@li... 
> [mailto:wra...@li...] *On Behalf Of *Tom 
> Saulpaugh
> *Sent:* Wednesday, September 26, 2007 10:52 AM
> *To:* wra...@li...
> *Subject:* Re: [Wrapper-user] 4096MB heap limit
>
> I did:
>
> wrapper.java.additional.13=-Xms6000
>
> wrapper.java.additional.14=-Xmx6000
>
> and it still pegs the heap at 4096.
>
> Are you using the most current version? If not, which version are you 
> using?
>
> Thanks,
>
> Tom
>
> ------------------------------------------------------------------------
>
> *From:* wra...@li... 
> [mailto:wra...@li...] *On Behalf Of 
> *Chandra Patni
> *Sent:* Wednesday, September 26, 2007 10:18 AM
> *To:* wra...@li...
> *Subject:* Re: [Wrapper-user] 4096MB heap limit
>
> I have also highlighted this issue before. The workaround is to use
>
> java.additional.N=-Xmx…
>
> Don’t use built-in parameters in wrapper.
>
> ------------------------------------------------------------------------
>
> *From:* wra...@li... 
> [mailto:wra...@li...] *On Behalf Of *Tom 
> Saulpaugh
> *Sent:* Wednesday, September 26, 2007 9:39 AM
> *To:* wra...@li...
> *Subject:* [Wrapper-user] 4096MB heap limit
>
> In my previous post I was referring to this code block within wrapper.c
>
> /* Maximum JVM memory */
>
> maxMemory = getIntProperty(properties, "wrapper.java.maxmemory", 0);
>
> if (maxMemory > 0) {
>
> maxMemory = __min(__max(maxMemory, initMemory), 4096); /* initMemory 
> <= n <= 4096 */
>
> if (strings) {
>
> strings[index] = malloc(sizeof(char) * (5 + 4 + 1)); /* Allow up to 4 
> digits. */
>
> sprintf(strings[index], "-Xmx%dm", maxMemory);
>
> }
>
> index++;
>
> }
>
> In the most recent wrapper.c the code has been changed to:
>
> /* Maximum JVM memory */
>
> maxMemory = getIntProperty(properties, "wrapper.java.maxmemory", 0);
>
> if (maxMemory > 0) {
>
> maxMemory = __max(maxMemory, initMemory); /* initMemory <= n */
>
> if (strings) {
>
> strings[index] = malloc(sizeof(char) * (5 + 4 + 1)); /* Allow up to 4 
> digits. */
>
> if (!strings[index]) {
>
> outOfMemory("WBJCAI", 9);
>
> return -1;
>
> }
>
> sprintf(strings[index], "-Xmx%dm", maxMemory);
>
> }
>
> index++;
>
> }
>
> which doesn't set a 4096MB limit. Is there any other code setting a limit?
>
> Has anyone created a >4GB heap?
>
> Thanks,
>
> Tom
>

Re: [Wrapper-user] Problems with wrapper and Windows

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

Juliana,
What version of the Wrapper are you using?

Is this something you are able to reproduce?  If so, try running it with
wrapper.debug enabled.  Seeing more precisely where it crashed
would give me something to go on.

Leif

Juliana Jacques Leroy wrote:
> Hi all,
>
> Sometimes the wrapper.exe is canceling with windows. I get this error in the EventViewer:
>
> -------------------------------------------------------------------------------------------------------------------------------------------------
> Event Type: Information
> Event Source: DrWatson
> Event Category: None
> Event ID: 4097
> Date: 26/9/2007
> Time: 14:36:00
> User: N/A
> Computer: SCX340242
> Description:
> The application, C:\SADSXP\TelnetDService\bin\wrapper.exe, generated an application error The error occurred on 09/26/2007 @ 14:35:58.041 The exception generated was c0000005 at address 0040E42A (wrapper)
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Any ideas?
> I'm running Windows Server 2003 Enterprise Edition.
>
> Thanks,
> Juliana.

[Wrapper-user] Problems with wrapper and Windows

[Juliana J. L. <Ju...@ms...>]

Hi all,

Sometimes the wrapper.exe is canceling with windows. I get this error in the=
 EventViewer:

----------------------------------------------------------------------------=
---------------------------------------------------------------------
Event Type: Information
Event Source: DrWatson
Event Category: None
Event ID: 4097
Date: 26/9/2007
Time: 14:36:00
User: N/A
Computer: SCX340242
Description:
The application, C:\SADSXP\TelnetDService\bin\wrapper.exe, generated an appl=
ication error The error occurred on 09/26/2007 @ 14:35:58.041 The exception =
generated was c0000005 at address 0040E42A (wrapper)
----------------------------------------------------------------------------=
---------------------------------------------------------------------

Any ideas?
I'm running Windows Server 2003 Enterprise Edition.

Thanks,
Juliana.

Esta mensagem e seus anexos s=E3o destinados exclusivamente ao(s) destinat=E1=
rio(s) identificado(s) acima e informa=E7=F5es confidenciais sujeitas a rest=
ri=E7=E3o legal e contratual. Caso V. Sa. tenha recebido esta mensagem por e=
ngano, fique ciente de que a distribui=E7=E3o, divulga=E7=E3o ou dissemina=E7=
=E3o das informa=E7=F5es nela contidas =E9 terminantemente proibida e poder=E1=
 caracterizar il=EDcito civil e penal, sujeitando o respons=E1vel =E0s penal=
idades aplic=E1veis. Neste caso, solicitamos a gentileza de retorn=E1-la de =
imediato ao remetente, eliminando-a automaticamente de seu sistema. Em caso =
de d=FAvida, queira, por favor, entrar em contato conosco por meio dos telef=
ones ou e-mail acima indicados.

This message and its attachments are addressed solely to the persons above a=
nd may contain privileged and confidential information. If you have received=
 the message in error, the distribution or dissemination of the content ther=
e of is prohibited. Please return it immediately to the sender and please de=
lete the message from your system. Should you have any questions, please con=
tact us.

Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMB=
IENTE.

Re: [Wrapper-user] 4096MB heap limit

[Chandra P. <cp...@ig...>]

Wrapper-3.2.3 64 bit for linux

Make sure that you have not specified wrapper.java.initmemory and
wrapper.java.maxmemory.=20

=20

BTW, you've not specified the units of memory and the default unit is
byte.

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html

=20

=20

________________________________

From: wra...@li...
[mailto:wra...@li...] On Behalf Of Tom
Saulpaugh
Sent: Wednesday, September 26, 2007 10:52 AM
To: wra...@li...
Subject: Re: [Wrapper-user] 4096MB heap limit

=20

I did:

=20

wrapper.java.additional.13=3D-Xms6000

wrapper.java.additional.14=3D-Xmx6000

=20

and it still pegs the heap at 4096.

=20

Are you using the most current version?  If not, which version are you
using?

=20

Thanks,

=20

Tom

=20

________________________________

From: wra...@li...
[mailto:wra...@li...] On Behalf Of Chandra
Patni
Sent: Wednesday, September 26, 2007 10:18 AM
To: wra...@li...
Subject: Re: [Wrapper-user] 4096MB heap limit

=20

I have also highlighted this issue before. The workaround is to use=20

java.additional.N=3D-Xmx...

=20

Don't use built-in parameters in wrapper.

=20

________________________________

From: wra...@li...
[mailto:wra...@li...] On Behalf Of Tom
Saulpaugh
Sent: Wednesday, September 26, 2007 9:39 AM
To: wra...@li...
Subject: [Wrapper-user] 4096MB heap limit

=20

In my previous post I was referring to this code block within wrapper.c

=20

    /* Maximum JVM memory */

    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", =
0);

    if (maxMemory > 0) {

        maxMemory =3D __min(__max(maxMemory, initMemory), 4096);  /*
initMemory <=3D n <=3D 4096 */

        if (strings) {

            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /*
Allow up to 4 digits. */

            sprintf(strings[index], "-Xmx%dm", maxMemory);

        }

        index++;

    }

=20

In the most recent wrapper.c the code has been changed to:

=20

    /* Maximum JVM memory */

    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", =
0);

    if (maxMemory > 0) {

        maxMemory =3D __max(maxMemory, initMemory);  /* initMemory <=3D =
n */

        if (strings) {

            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /*
Allow up to 4 digits. */

            if (!strings[index]) {

                outOfMemory("WBJCAI", 9);

                return -1;

            }

            sprintf(strings[index], "-Xmx%dm", maxMemory);

        }

        index++;

    }

=20

which doesn't set a 4096MB limit.  Is there any other code setting a
limit?

Has anyone created a >4GB heap?

=20

Thanks,

=20

Tom

=20

Notice: This email and any files transmitted with it are confidential
and intended solely for the individual or entity to which they are
addressed. If you have received this email in error please notify the
sender and destroy any copies of this email and its attachments. You are
hereby notified that any unauthorized review, use, disclosure,
dissemination, distribution, or copying of this communication, or any of
its contents, is strictly prohibited. Please note that any views or
opinions presented in this email are solely those of the author and do
not necessarily represent those of the company. The recipient should
check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus
transmitted by this email.=20

Re: [Wrapper-user] 4096MB heap limit

[Tom S. <Tom...@Me...>]

I did:

wrapper.java.additional.13=3D-Xms6000
wrapper.java.additional.14=3D-Xmx6000

and it still pegs the heap at 4096.

Are you using the most current version?  If not, which version are you usin=
g?

Thanks,

Tom

________________________________
From: wra...@li... [mailto:wrapper-user-bounc=
es...@li...] On Behalf Of Chandra Patni
Sent: Wednesday, September 26, 2007 10:18 AM
To: wra...@li...
Subject: Re: [Wrapper-user] 4096MB heap limit

I have also highlighted this issue before. The workaround is to use
java.additional.N=3D-Xmx...

Don't use built-in parameters in wrapper.

________________________________
From: wra...@li... [mailto:wrapper-user-bounc=
es...@li...] On Behalf Of Tom Saulpaugh
Sent: Wednesday, September 26, 2007 9:39 AM
To: wra...@li...
Subject: [Wrapper-user] 4096MB heap limit

In my previous post I was referring to this code block within wrapper.c

    /* Maximum JVM memory */
    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", 0);
    if (maxMemory > 0) {
        maxMemory =3D __min(__max(maxMemory, initMemory), 4096);  /* initMe=
mory <=3D n <=3D 4096 */
        if (strings) {
            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /* Allo=
w up to 4 digits. */
            sprintf(strings[index], "-Xmx%dm", maxMemory);
        }
        index++;
    }

In the most recent wrapper.c the code has been changed to:

    /* Maximum JVM memory */
    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", 0);
    if (maxMemory > 0) {
        maxMemory =3D __max(maxMemory, initMemory);  /* initMemory <=3D n *=
/
        if (strings) {
            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /* Allo=
w up to 4 digits. */
            if (!strings[index]) {
                outOfMemory("WBJCAI", 9);
                return -1;
            }
            sprintf(strings[index], "-Xmx%dm", maxMemory);
        }
        index++;
    }

which doesn't set a 4096MB limit.  Is there any other code setting a limit?
Has anyone created a >4GB heap?

Thanks,

Tom


Notice: This email and any files transmitted with it are confidential and i=
ntended solely for the individual or entity to which they are addressed. If=
 you have received this email in error please notify the sender and destroy=
 any copies of this email and its attachments. You are hereby notified that=
 any unauthorized review, use, disclosure, dissemination, distribution, or =
copying of this communication, or any of its contents, is strictly prohibit=
ed. Please note that any views or opinions presented in this email are sole=
ly those of the author and do not necessarily represent those of the compan=
y. The recipient should check this email and any attachments for the presen=
ce of viruses. The company accepts no liability for any damage caused by an=
y virus transmitted by this email.

[Wrapper-user] Wrapper behavior on Solaris 10 zone

[ahmadk72 <reg...@in...>]

I have a problem that is perplexed me to no end.  Even our UNIX admin is
stumped, so this mailing list is a last resort.

We have a third-party application that uses the Java Service Wrapper
(v3.2.1).  The application is installed on two different Zones in Solaris
10.  One zone is called rhdam-dev and the other is called rhdam-tst.

If i startup the rhdam-dev (DEV box) application, the Java service wrapper
uses ports 31000 and 32000 for communicating to and listening from the JVM.
Everything works fine, and I have no problems running the application as
expected.

Then recently we installed the application on the dam-tst (TEST box)
application on another Solaris zone.  When the wrapper starts up, I see the
following error (logging output is set to DEBUG level) in the attached log
file.

>From what I have been able to deciper, it is complaining about port 32000
already being in use.  However, the port is not in use on the rhdam-tst
zone.  I can run a netstat -an command and see that there is nothing running
on port 32000.

The really weird part is that is I stop the wrapper service on the rhdam-dev
zone, and try to startup the rhdam-tst instance, then the wrapper service
starts successfully.

For now I have been able to start both up by changing adding the
wrapper.port.min and wrappper.port.max settings so the ports don't conflict
between rhdam-dev and rhdam-tst.

However, I need to know why this is happening.  Has anyone seen this
behavior?  The ports are suppose to be independent on Solaris zone.  Why is
the Java Service wrapper socket complaining about the port being used in
another zone.

If anyone can help me solve this mystery that would be just great.

Thanks

Kashif http://www.nabble.com/file/p12904287/artesia-service-wrapper.log
artesia-service-wrapper.log 
-- 
View this message in context: http://www.nabble.com/Wrapper-behavior-on-Solaris-10-zone-tf4523339.html#a12904287
Sent from the Java Service Wrapper mailing list archive at Nabble.com.

Re: [Wrapper-user] 4096MB heap limit

[Chandra P. <cp...@ig...>]

I have also highlighted this issue before. The workaround is to use=20

java.additional.N=3D-Xmx...

=20

Don't use built-in parameters in wrapper.

=20

________________________________

From: wra...@li...
[mailto:wra...@li...] On Behalf Of Tom
Saulpaugh
Sent: Wednesday, September 26, 2007 9:39 AM
To: wra...@li...
Subject: [Wrapper-user] 4096MB heap limit

=20

In my previous post I was referring to this code block within wrapper.c

=20

    /* Maximum JVM memory */

    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", =
0);

    if (maxMemory > 0) {

        maxMemory =3D __min(__max(maxMemory, initMemory), 4096);  /*
initMemory <=3D n <=3D 4096 */

        if (strings) {

            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /*
Allow up to 4 digits. */

            sprintf(strings[index], "-Xmx%dm", maxMemory);

        }

        index++;

    }

=20

In the most recent wrapper.c the code has been changed to:

=20

    /* Maximum JVM memory */

    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", =
0);

    if (maxMemory > 0) {

        maxMemory =3D __max(maxMemory, initMemory);  /* initMemory <=3D =
n */

        if (strings) {

            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /*
Allow up to 4 digits. */

            if (!strings[index]) {

                outOfMemory("WBJCAI", 9);

                return -1;

            }

            sprintf(strings[index], "-Xmx%dm", maxMemory);

        }

        index++;

    }

=20

which doesn't set a 4096MB limit.  Is there any other code setting a
limit?

Has anyone created a >4GB heap?

=20

Thanks,

=20

Tom

=20

Notice: This email and any files transmitted with it are confidential
and intended solely for the individual or entity to which they are
addressed. If you have received this email in error please notify the
sender and destroy any copies of this email and its attachments. You are
hereby notified that any unauthorized review, use, disclosure,
dissemination, distribution, or copying of this communication, or any of
its contents, is strictly prohibited. Please note that any views or
opinions presented in this email are solely those of the author and do
not necessarily represent those of the company. The recipient should
check this email and any attachments for the presence of viruses. The
company accepts no liability for any damage caused by any virus
transmitted by this email.=20

[Wrapper-user] 4096MB heap limit

[Tom S. <Tom...@Me...>]

In my previous post I was referring to this code block within wrapper.c

    /* Maximum JVM memory */
    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", =
0);
    if (maxMemory > 0) {
        maxMemory =3D __min(__max(maxMemory, initMemory), 4096);  /* =
initMemory <=3D n <=3D 4096 */
        if (strings) {
            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /* =
Allow up to 4 digits. */
            sprintf(strings[index], "-Xmx%dm", maxMemory);
        }
        index++;
    }

In the most recent wrapper.c the code has been changed to:

    /* Maximum JVM memory */
    maxMemory =3D getIntProperty(properties, "wrapper.java.maxmemory", =
0);
    if (maxMemory > 0) {
        maxMemory =3D __max(maxMemory, initMemory);  /* initMemory <=3D =
n */
        if (strings) {
            strings[index] =3D malloc(sizeof(char) * (5 + 4 + 1));  /* =
Allow up to 4 digits. */
            if (!strings[index]) {
                outOfMemory("WBJCAI", 9);
                return -1;
            }
            sprintf(strings[index], "-Xmx%dm", maxMemory);
        }
        index++;
    }

which doesn't set a 4096MB limit.  Is there any other code setting a =
limit?
Has anyone created a >4GB heap?

Thanks,

Tom

--
Notice: This email and any files transmitted with it are confidential =
and intended solely for the individual or entity to which they are =
addressed.  If you have received this email in error please notify the =
sender and destroy any copies of this email and its attachments.  You =
are hereby notified that any unauthorized review, use, disclosure, =
dissemination, distribution, or copying of this communication, or any of =
its contents, is strictly prohibited.  Please note that any views or =
opinions presented in this email are solely those of the author and do =
not necessarily represent those of the company.  The recipient should =
check this email and any attachments for the presence of viruses.  The =
company accepts no liability for any damage caused by any virus =
transmitted by this email.

[Wrapper-user] JVM Heap Limit

[Tom S. <Tom...@Me...>]

I'm working on a 64-bit windows port.
In wrapper.c the code seems to max out heap size at 4GB.
What is the reason for this?  I'd like to set it at 6GB.
Is there a convention for getting around this?

Thanks,

Tom

--
Notice: This email and any files transmitted with it are confidential =
and intended solely for the individual or entity to which they are =
addressed.  If you have received this email in error please notify the =
sender and destroy any copies of this email and its attachments.  You =
are hereby notified that any unauthorized review, use, disclosure, =
dissemination, distribution, or copying of this communication, or any of =
its contents, is strictly prohibited.  Please note that any views or =
opinions presented in this email are solely those of the author and do =
not necessarily represent those of the company.  The recipient should =
check this email and any attachments for the presence of viruses.  The =
company accepts no liability for any damage caused by any virus =
transmitted by this email.

[Wrapper-user] Normalising HP-UX architectures

[Rob O. <rox...@im...>]

An HP system we have here is reporting itself as 9000/785 and rather
than add an extra element to the case statement I've added a sed command
to turn all 9000/* architectures into parisc.  This seems to work well
for us so I've attached a patch against the trunk rev.  

It would be nice if the .sl could be named using the same convention but
for now (using the 3.2.3 jar) its using "pa_risc2.0" which we're working
around.

Hope that helps,

Rob
  Rob Oxspring
  rox...@im...

Re: [Wrapper-user] Using the wrapper for notification

[Chuck W. <ch...@ma...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Jeff,<br>
<br>
I've found that wrapper restarts frequently happen when the app is in
some kind of a bad state that leads to failure to respond to the
wrapper ping.  In this state I wouldn't trust an email notification to
actually get out, so would suggest one of two approaches:<br>
<ol>
  <li>Send the email from the application after it restarts, or</li>
  <li>Send the email from the native wrapper code, i.e. the wrapper's
monitor, by modifying that code to do so (not sure if there is some
hook there already that could be used)</li>
</ol>
Chuck<br>
<br>
<br>
Jeff Greif wrote on 09/24/2007 07:49 PM:
<blockquote cite="mid...@we..." type="cite">
  <pre wrap="">For production apps running on servers, it would be useful to associate 
wrapper actions (such as restart) with some kind of notification, e.g. 
an email to an administrator.

Until I noticed that the wrapper does not use some full-featured logging 
package like log4j, I thought perhaps I could add a log4j SmtpAppender 
and triggering-event filter to do this.

As the simplified logging facilities in the wrapper are not really aimed 
at this kind of use, the next idea was to do this email logging in the 
application, probably by replacing the WrapperSimpleApp class currently 
being used with a similar one which does the logging from the 
WrapperListener methods.  This main reason for using SmtpAppender to 
take care of the email is to minimize the code alteration requirements 
in the app, which already contains facilities for emailing, but might 
not be able to execute them if badly enough in need of restart.

Are there other suggestions?

Jeff



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
<a class="moz-txt-link-freetext" href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a>
_______________________________________________
Wrapper-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wra...@li...">Wra...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/wrapper-user">https://lists.sourceforge.net/lists/listinfo/wrapper-user</a>

!DSPAM:46f8a184233753708835974!

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

[Wrapper-user] Using the wrapper for notification

[Jeff G. <jg...@we...>]

For production apps running on servers, it would be useful to associate 
wrapper actions (such as restart) with some kind of notification, e.g. 
an email to an administrator.

Until I noticed that the wrapper does not use some full-featured logging 
package like log4j, I thought perhaps I could add a log4j SmtpAppender 
and triggering-event filter to do this.

As the simplified logging facilities in the wrapper are not really aimed 
at this kind of use, the next idea was to do this email logging in the 
application, probably by replacing the WrapperSimpleApp class currently 
being used with a similar one which does the logging from the 
WrapperListener methods.  This main reason for using SmtpAppender to 
take care of the email is to minimize the code alteration requirements 
in the app, which already contains facilities for emailing, but might 
not be able to execute them if badly enough in need of restart.

Are there other suggestions?

Jeff

Re: [Wrapper-user] Tanuki Wrapper 64Bit version for Windows

[Mattias A. <mai...@ca...>]

Hi,

I have compiled a 64-bit version of the wrapper. The instructions is
available here.

http://sourceforge.net/tracker/index.php?func=detail&aid=1635188&group_id=39428&atid=425190

Regards,
   /Mattias


> Hi Leif Mortenson,
>
> First of all, thank you for the good product. We are very satisfied and we
> want to go on using the wrapper (and we have given an
> donation ;-)).
> We are planning to test our application on a 64Bit Windows operating
> system and currently struggle with the 64bit version of the
> wrapper.
>
> I would be very happy if you could bring some light in the dark ;-) by
> anwering my questions.
>
> 1) I can not find a binary version for the 64 Bit version.
> 2) I see several questions from other developers who have the same problem
> but no very clear answer or different suggestions.
> 3) I can not find a concluding information by Tanuki about this task. Ok,
> I have the list of supported platforms, that does not
> include the 64Bit Windows platform...
>
> What I need to know:
>
> - Is the binary version somewhere available?
> - If not, can we expect such a version and if we can expect it, when can
> we expect it?
> - Is there an other way (build the version by ourselves) to get the 64Bit
> wrapper running on Windows64?
> - Do we have to look for an other tool, because we can not expect a
> solution in a acceptable time frame?
>
> Thank you for a explanation, that clarifies the questions all around this
> task.
>
> Best Regards,
>
> Dittmar Gross
> Manager arctic Technology
>
> -------------------------------------------------------------------------------------------------
> i:FAO Group
> Clemensstrasse 9, 60487 Frankfurt am Main, Germany Tel +49 (69) 7680-5341,
> Fax +49 (69) 7680-5100, eMail gr...@if...,
> www.cytric.info
>
> i:FAO Group GmbH
> Sitz in Frankfurt am Main
> Eingetragen beim Amtsgericht Frankfurt am Main, HRB 73600
> Geschäftsführer: Louis Arnitz, Karin Froese
>
> Diese Mitteilung ist nur für den Empfänger bestimmt. Wenn Sie nicht der
> bestimmungsgemäße Empfänger sind, werden Sie hiermit darauf
> hingewiesen, daß jede Nutzung, Vervielfältigung oder Verbreitung dieser
> eMail, auch in Auszügen, streng untersagt ist. Bitte
> informieren Sie den Absender durch Rücksendung der eMail und löschen Sie
> diese aus Ihrem System. Diese eMail stellt weder ein
> Vertragsangebot noch eine Vertragsergänzung oder -annahme dar, es sei
> denn, sie ist ausdrücklich oder eindeutig derart bezeichnet.
> Diese eMail stellt auch keine Zustimmung zur Verwendung der hierin
> enthaltenen Angaben für Zwecke des Direktmarketing oder zur
> Weitergabe von Daten an Dritte dar.
>
> To view the disclaimer text in other languages, click here:
> www.ifao.net/disclaimer
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>