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

Re: [Wrapper-user] Wrapper on CruiseControl doesn't work

[Marco T. <mt...@je...>]

I solved my problems thanks. It was a mixture of properties not set properly 
and an error occurring during the unit tests, since, on my system, the 
wrapper doesn't resolve Java system property user.home to C:/Documents And 
Settings/<username> but it resolves to C:/Documents And 
Settings/LocalService.

I bypassed this problem by having my unit tests to use a system environment 
variable that both Wrapper and Java would interpret as being the same.

Marco

----- Original Message ----- 
From: "Geoffrey Mitchell" <ga...@im...>
To: <wra...@li...>
Sent: Thursday, April 13, 2006 6:05 PM
Subject: Re: [Wrapper-user] Wrapper on CruiseControl doesn't work


>I just avoid relative paths, which I generally think is a good idea anyway. 
>It's good to know that that property is there now, though.  I will probably 
>make use of it in the future.  In my current implementation, I have hacked 
>the wrapper script to not change the working directory, and it works great!
>
> Leif Mortenson wrote:
>
>> Geoffrey,
>>
>>> I know that Cruise and the wrapper both have some expectations regarding 
>>> your current working directory (something I personally regard as a sin, 
>>> but that's just my opinion).
>>
>> I actually agree with you.  But the problem is that the working directory 
>> is not consistent
>> between running as a console app and running as a service under windows. 
>> When run
>> as a service, the working directory is always set to the system32 
>> directory.   This means
>> that relative paths in an application become pretty much impossible.   I 
>> always like being
>> able to write apps that are deployed as a zip or tar file and then 
>> unpackaged anyplace
>> and run.   Having a known fixed working directory as a base makes 
>> everything just work.
>>
>
>
> -------------------------------------------------------
> 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 E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

[Wrapper-user] Help with service settings

[Marco T. <mt...@je...>]

Hi, I managed to install CruiseControl as a service now, and also the builds 
are working fine. Except from one particular problem. One of my unit tests 
checks for a properties file in the ${user.home} Java system property, which 
points to C:\Documents and Settings\<username>. However, Wrapper considers 
this property as pointing to C:\Documents and Settings\LocalService. Hence 
it can't find the file at this location, and the test fails. If I run 
wrapper.exe -c wrapper.conf everything works fine. How to I tell Wrapper to 
consider the user home directory as C:\Documents and Settings\<username>?

I tried with set.USER_HOME=C:/Documents and Settings/mtedone/ but with the 
same result.

Marco 


---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

Re: [Wrapper-user] Wrapper on CruiseControl doesn't work

[Geoffrey M. <ga...@im...>]

I just avoid relative paths, which I generally think is a good idea 
anyway.  It's good to know that that property is there now, though.  I 
will probably make use of it in the future.  In my current 
implementation, I have hacked the wrapper script to not change the 
working directory, and it works great!

Leif Mortenson wrote:

> Geoffrey,
>
>> I know that Cruise and the wrapper both have some expectations 
>> regarding your current working directory (something I personally 
>> regard as a sin, but that's just my opinion).
>
> I actually agree with you.  But the problem is that the working 
> directory is not consistent
> between running as a console app and running as a service under 
> windows.   When run
> as a service, the working directory is always set to the system32 
> directory.   This means
> that relative paths in an application become pretty much impossible.   
> I always like being
> able to write apps that are deployed as a zip or tar file and then 
> unpackaged anyplace
> and run.   Having a known fixed working directory as a base makes 
> everything just work.
>

Re: [Wrapper-user] Wrapper on CruiseControl doesn't work

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

Geoffrey,
> I know that Cruise and the wrapper both have some expectations 
> regarding your current working directory (something I personally 
> regard as a sin, but that's just my opinion).
I actually agree with you.  But the problem is that the working 
directory is not consistent
between running as a console app and running as a service under 
windows.   When run
as a service, the working directory is always set to the system32 
directory.   This means
that relative paths in an application become pretty much impossible.   I 
always like being
able to write apps that are deployed as a zip or tar file and then 
unpackaged anyplace
and run.   Having a known fixed working directory as a base makes 
everything just work.

Newer versions of the wrapper let you change the working directory using the
wrapper.working.dir property:
http://wrapper.tanukisoftware.org/doc/english/prop-working-dir.html

The first couple versions (pre-sourceforge) didn't do this, but it meant 
a constant stream
of path related problems.   An app would work differently if you did this:
c:\MyDir\MyApp\bin> MyApp.bat
versus this:
c:\MyDir\MyApp> bin\MyApp.bat

As things are now, everything just works regardless of how the app is 
launched or
where it is installed.

Cheers,
Leif

Re: [Wrapper-user] Wrapper on CruiseControl doesn't work

[Geoffrey M. <ga...@im...>]

I am runing Cruise successfully under the wrapper, but on Linux, not 
windows. 

Odds are good that it is a permissions issue of some sort.  From what I 
have seen, 9 out of 10 problems making an app work with wrapper are 
permissions related.  Make sure that your service is running as the same 
user that you are testing as.

I know that Cruise and the wrapper both have some expectations regarding 
your current working directory (something I personally regard as a sin, 
but that's just my opinion).  I believe that the wrapper, by default, 
changes your current working directory to the location of the wrapper 
script.  Cruise tries to write the serialized project file to the 
current working directory, so if the location of the wrapper script is 
not writeable, you will have problems with losing your build number, 
etc. when the service is re-started.  This probably isn't your specific 
problem, but is something to watch out for. 


Marco Tedone wrote:

> Hi, I'm installing CruiseControl as an NT service, using the wrapper. 
> I found some examples on the net on how to configure CruiseControl.
>
> This is my configuration file:
>
> [begin]
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>
> # Java Classpath (include wrapper.jar)  Add class path elements as
> #  needed starting from 1
> wrapper.java.classpath.1=D:/OPENSOURCES\cruisecontrol-2.4.1/main/lib/*.jar 
>
> wrapper.java.classpath.2=D:/OPENSOURCES/apache-ant-1.6.5/lib/*.jar
> wrapper.java.classpath.3=D:/OPENSOURCES\cruisecontrol-2.4.1/main/dist/cruisecontrol.jar 
>
> wrapper.java.classpath.4=D:/J2SE/lib/*.jar
> wrapper.java.classpath.5=./*.jar
>
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=./
>
>
> # Java Additional Parameters
> wrapper.java.additional.1=-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder 
>
>
> # Initial Java Heap Size (in MB)
> wrapper.java.initmemory=128
>
> # Maximum Java Heap Size (in MB)
> wrapper.java.maxmemory=256
>
> # Application parameters.  Add parameters as needed starting from 1
> wrapper.app.parameter.1=CruiseControl
> wrapper.app.parameter.2=-jmxport 8000
>
>
> # Port which the native wrapper code will attempt to connect to
> wrapper.port=1777
>
>
>
> #********************************************************************
> # Wrapper NT 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=CruiseControl
>
> # Display name of the service
> wrapper.ntservice.displayname=CruiseControl Service (v2.4.1)
>
> # Description of the service
> wrapper.ntservice.description=Continuous integration builds \
> and tests with JUnit, Ant and CruiseControl.
>
> # 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
>
> # Priority at which the service is run.  NORMAL, LOW, HIGH, or
> #  REALTIME
> wrapper.ntservice.process_priority=NORMAL
>
> # Allow the service to interact with the desktop.
> wrapper.ntservice.interactive=true
>
> [end]
>
> The service installs fine and starts fine, also CruiseControl picks up 
> the changes in the SCM repository. However, all the builds are 
> successfull (although these should be broken) and there is no real 
> output in the xml files generated by CruiseControl.
>
> However, when I start CruiseControl with the cruisecontrol.bat 
> command, everything works fine. Any idea?
>
> Marco
>
>
> ---
> [This E-mail has been scanned for viruses but it is your 
> responsibility to maintain up to date anti virus software on the 
> device that you are
> currently using to read this email. ]
>
>
>
> -------------------------------------------------------
> 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] Program starts as a service but GUI not displayed

[Brian N. <ng...@ya...>]

Hi there,
 
I have written a program using JDK 1.6 beta, and am making use of some of the new features. The program starts up on system boot as a service on Windows XP, but the neither the GUI or the system tray icon are displayed.
 
Can anyone help me out with this problem? Is it that JDK 1.6 is not supported?
 
Any advice would be much appreciated.
 
Thanks

		
---------------------------------
  Yahoo! Cars NEW - sell your car and browse thousands of new and used cars online search now  
---------------------------------
  

Re: [Wrapper-user] Wrapper on CruiseControl doesn't work

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

Marco,
    Sorry, never used cruise control myself.  The wrapper.conf file 
looks valid.
But it may not be correct for this particular app.   Someone else on 
this list
might have an answer.  But you would probably have more luck asking
someone at the CruiseControl project.

Cheers,
Leif

Marco Tedone wrote:
> Hi, I'm installing CruiseControl as an NT service, using the wrapper. 
> I found some examples on the net on how to configure CruiseControl.
>
> This is my configuration file:
>
> [begin]
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>
> # Java Classpath (include wrapper.jar)  Add class path elements as
> #  needed starting from 1
> wrapper.java.classpath.1=D:/OPENSOURCES\cruisecontrol-2.4.1/main/lib/*.jar 
>
> wrapper.java.classpath.2=D:/OPENSOURCES/apache-ant-1.6.5/lib/*.jar
> wrapper.java.classpath.3=D:/OPENSOURCES\cruisecontrol-2.4.1/main/dist/cruisecontrol.jar 
>
> wrapper.java.classpath.4=D:/J2SE/lib/*.jar
> wrapper.java.classpath.5=./*.jar
>
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=./
>
>
> # Java Additional Parameters
> wrapper.java.additional.1=-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder 
>
>
> # Initial Java Heap Size (in MB)
> wrapper.java.initmemory=128
>
> # Maximum Java Heap Size (in MB)
> wrapper.java.maxmemory=256
>
> # Application parameters.  Add parameters as needed starting from 1
> wrapper.app.parameter.1=CruiseControl
> wrapper.app.parameter.2=-jmxport 8000
>
>
> # Port which the native wrapper code will attempt to connect to
> wrapper.port=1777
>
>
>
> #********************************************************************
> # Wrapper NT 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=CruiseControl
>
> # Display name of the service
> wrapper.ntservice.displayname=CruiseControl Service (v2.4.1)
>
> # Description of the service
> wrapper.ntservice.description=Continuous integration builds \
> and tests with JUnit, Ant and CruiseControl.
>
> # 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
>
> # Priority at which the service is run.  NORMAL, LOW, HIGH, or
> #  REALTIME
> wrapper.ntservice.process_priority=NORMAL
>
> # Allow the service to interact with the desktop.
> wrapper.ntservice.interactive=true
>
> [end]
>
> The service installs fine and starts fine, also CruiseControl picks up 
> the changes in the SCM repository. However, all the builds are 
> successfull (although these should be broken) and there is no real 
> output in the xml files generated by CruiseControl.
>
> However, when I start CruiseControl with the cruisecontrol.bat 
> command, everything works fine. Any idea?
>
> Marco
>
>
> ---
> [This E-mail has been scanned for viruses but it is your 
> responsibility to maintain up to date anti virus software on the 
> device that you are
> currently using to read this email. ]
>
>
>
> -------------------------------------------------------
> 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] NewB?: Wrap Multiple Java Apps...

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

Kit,
A single Wrapper is only capable of controlling a single JVM.   You can 
however, easily
run multiple copies of the wrapper.  If each is given a unique service 
name, they can all
be independently run as services as well.  That is the safest way to run 
multiple JVMs
as they can each be monitored and restarted correctly.   The 
applications all need to
be designed to handle restarts of children or parents correctly however.

Cheers,
Leif

Kit Plummer wrote:
> After spending about 30 minutes trying to determine if JSW supported 
> the control of multiple JVMs...I decided to play ignorant and just ask.
>
> So, can JSW control multiple JVMs from one script?  I have a handful 
> of PicoContainer-based services that i'd like to be able to launch, 
> monitor and control from a parent application.  Is this within the realm?
>
> Sorry for need reading until my eyes bled.  I did see a few threads in 
> the archive that were close, but not sure.
>
> TIA,
> Kit
>

[Wrapper-user] NewB?: Wrap Multiple Java Apps...

[Kit P. <chr...@ra...>]

After spending about 30 minutes trying to determine if JSW supported the 
control of multiple JVMs...I decided to play ignorant and just ask.

So, can JSW control multiple JVMs from one script?  I have a handful of 
PicoContainer-based services that i'd like to be able to launch, monitor 
and control from a parent application.  Is this within the realm?

Sorry for need reading until my eyes bled.  I did see a few threads in 
the archive that were close, but not sure.

TIA,
Kit

-- 
Kit Plummer

[Wrapper-user] Wrapper on CruiseControl doesn't work

[Marco T. <mt...@je...>]

Hi, I'm installing CruiseControl as an NT service, using the wrapper. I 
found some examples on the net on how to configure CruiseControl.

This is my configuration file:

[begin]
wrapper.java.command=%JAVA_HOME%/bin/java

wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=D:/OPENSOURCES\cruisecontrol-2.4.1/main/lib/*.jar
wrapper.java.classpath.2=D:/OPENSOURCES/apache-ant-1.6.5/lib/*.jar
wrapper.java.classpath.3=D:/OPENSOURCES\cruisecontrol-2.4.1/main/dist/cruisecontrol.jar
wrapper.java.classpath.4=D:/J2SE/lib/*.jar
wrapper.java.classpath.5=./*.jar


# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=./


# Java Additional Parameters
wrapper.java.additional.1=-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder

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

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

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=CruiseControl
wrapper.app.parameter.2=-jmxport 8000


# Port which the native wrapper code will attempt to connect to
wrapper.port=1777



#********************************************************************
# Wrapper NT 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=CruiseControl

# Display name of the service
wrapper.ntservice.displayname=CruiseControl Service (v2.4.1)

# Description of the service
wrapper.ntservice.description=Continuous integration builds \
and tests with JUnit, Ant and CruiseControl.

# 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

# Priority at which the service is run.  NORMAL, LOW, HIGH, or
#  REALTIME
wrapper.ntservice.process_priority=NORMAL

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

[end]

The service installs fine and starts fine, also CruiseControl picks up the 
changes in the SCM repository. However, all the builds are successfull 
(although these should be broken) and there is no real output in the xml 
files generated by CruiseControl.

However, when I start CruiseControl with the cruisecontrol.bat command, 
everything works fine. Any idea?

Marco


---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

Re: [Wrapper-user] restart tuning

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

Leif,
What I want is not exactly to disable restarts, although the combination 
you describe could work for me. What I really think is best for me is if 
the wrapper can identify all abnormal termination runs as failed runs.
Thanks for the continued interest,
Anat

Leif Mortenson wrote:
> Anat,
>    The ability to disable restarts does interest other users, this is 
> why I added the
> wrapper.disable_restarts property:
> http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html
>
>    The problem is that in your case, you would like a combination.  
> You would
> like to allow one restart, if it was requested from the JVM, but no 
> others.
>
>    Let me think about it.  I may need a property to deal with all
> non-WrapperManager.restart() restarts.
>
>    Cheers,
>    Leif
>
> Anat Halpern wrote:
>> Leif and David - thanks for the quick replies.
>>
>> Leif Mortenson wrote:
>>> In most cases, setting a hard number of restarts of 5 would be bad 
>>> for an application
>>> that crashes once in a while.  It would restart 5 times over say a 
>>> month and then
>>> suddenly fail to come up a 6th time.  This is why the successful 
>>> invocation time
>>> exists to allow this counter the be reset.
>> I understand this. In my case, however, I don't want to allow any 
>> crashes of the application. In any case, I'd like to know of these 
>> crashes, so I could fix the bugs causing them. This is especially 
>> importance in a service version, where people are likely to forget 
>> that the application is even running, and so wouldn't notice frequent 
>> crashes, as long as the application restarts.
>>
>> I have no problem using the workaround of setting a large value for 
>> max invocations, if you don't think this could interest other people.
>>
>> Cheers,
>> 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.

[Wrapper-user] Re: Using JSW To Run a Java Server on a Privileged Port?

[Jason B. <jas...@gm...>]

On 4/9/06, Leif Mortenson <le...@ta...> wrote:
> Jason,
>     This is discussed in this feature request.
> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D490806&group=
_id=3D39428&atid=3D425190
>     If there is anything that I have overlooked, feel free to add to
> this issue.  It is
> something I would like to make available, I am just not sure how.

Thanks for the link.  I figured I wouldn't be the first to ask about
it.  I'll add to the
issue.

>     The problem is that the Tomcat loader binds to the port as root and
> then changes to
> another user while maintaining a reference to the port.   Once the user
> has been changed,
> there is of course no way to go back to being root.
>
>     The Wrapper could do something like this once, but it would not be
> possible to recover
> from failures and launch a new JVM as that would require becoming root a
> second time.

From what I can tell, jsvc does not do it this way.  So, you should really =
have
a look at their implementation.  I believe it's something you could add to =
JSW.

>     In your case, it sounds like you want to let your live users connect
> directly to Tomcat.

I do indeed.

> I haven't used the newest version, but older versions were not really
> designed for this.

As of at least 3 years ago they were.  This is an area where Tomcat has
improved every year for many years.  At this point, Tomcat is at least as f=
ast
at serving static content as Apache httpd.

> Usually, you would have Apache running and then connect to Tomcat using
> mod_jk.

That pattern is still popular, but slows down Tomcat.  I no longer suggest =
this
pattern, mainly because Tomcat stand-alone is plenty capable now, and setti=
ng
up two servers (both httpd and Tomcat), plus a connector to connect them is
much more difficult to get working, and to maintain.  And, Tomcat is now fu=
ll
featured enough that most people don't need Apache httpd anymore (although
most don't realize this).

> This makes it possible for Tomcat to only need high ports, resolving
> this problem completely.

And creating the problem of lower performance, more difficult maintenance,
more difficult troubleshooting since you have two servers involved in each
request, etc..  Some folks will always set up Tomcat behind httpd, and will
insist that it is the right way, but that's more of a resistance to change =
than
anything.  Meanwhile, a large percentage of Tomcat users are now happily
using it without Apache httpd. and they want to run it on port 80 as a non-=
root
user.

Thanks.

--
Jason Brittain

Re: [Wrapper-user] Timeout/Shutdown

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

Jim,
    What version of the Wrapper are you using?  If 3.1.2, try setting the
wrapper.use_system_time=FALSE property.  It is default in 3.2.0.   This 
new timing
mechanism handles heavily loaded systems much better.

    If that fails, it may be necessary to set the following two timeout 
properties.
Be sure to familiarize yourself with the docs of any of these properties 
before
setting them however.
wrapper.cpu.timeout=180
wrapper.ping.timeout=300

http://wrapper.tanukisoftware.org/doc/english/prop-cpu-timeout.html
http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html

    These will probably get rid of the problems you are seeing, but they 
will
also slow down the Wrapper's ability to recover from a crashed jvm.

Cheers,
Leif

Jim Redman wrote:
> We have a graphical application that we run as an .exe using the 
> wrapper.  It restarts on a timeout:
>
> ERROR  | wrapper  | 2006/04/07 00:08:05 | JVM appears hung: Timed out 
> waiting for signal from JVM.
> ERROR  | wrapper  | 2006/04/07 00:08:05 | JVM did not exit on request, 
> terminated
>
> I don't really case about the wrapper timeout, the application is 
> interactive and the user can take care of real problems, but I'm 
> wondering what we're doing that's causing a problem.
>
> Are the "pings" sent from the Java Event thread?    The application 
> could use a little optimization and is a memory hog.  We tend to go 
> into phases in the program where we'll take 100% CPU time, such as 
> compiling applications, so we get, eg this:
>
> INFO   | wrapper  | 2006/04/06 23:32:15 | Wrapper Process has not 
> received any CPU time for 141 seconds.  Extending timeouts.
>
> but even during this the screen is repainting (usually and slowly).
>
> Not too important, but any thoughts appreciated.
>
> Jim
>

Re: [Wrapper-user] restart tuning

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

Anat,
    The ability to disable restarts does interest other users, this is 
why I added the
wrapper.disable_restarts property:
http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html

    The problem is that in your case, you would like a combination.  You 
would
like to allow one restart, if it was requested from the JVM, but no others.

    Let me think about it.  I may need a property to deal with all
non-WrapperManager.restart() restarts.

    Cheers,
    Leif

Anat Halpern wrote:
> Leif and David - thanks for the quick replies.
>
> Leif Mortenson wrote:
>> In most cases, setting a hard number of restarts of 5 would be bad 
>> for an application
>> that crashes once in a while.  It would restart 5 times over say a 
>> month and then
>> suddenly fail to come up a 6th time.  This is why the successful 
>> invocation time
>> exists to allow this counter the be reset.
> I understand this. In my case, however, I don't want to allow any 
> crashes of the application. In any case, I'd like to know of these 
> crashes, so I could fix the bugs causing them. This is especially 
> importance in a service version, where people are likely to forget 
> that the application is even running, and so wouldn't notice frequent 
> crashes, as long as the application restarts.
>
> I have no problem using the workaround of setting a large value for 
> max invocations, if you don't think this could interest other people.
>
> Cheers,
> Anat

Re: [Wrapper-user] Delta Pack fails when run in a Windows folder with spaces in the path

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

Patrick,
    Thanks for pointing this out.  It is a known problem that has 
already been fixed for
the next release.   I sent out a note about this a few days after the 
3.2.0 release.
https://sourceforge.net/mailarchive/message.php?msg_id=15098035

    It doesn't look like the patched files can be downloaded from the 
archive.
I'll append the contents of src\bin\App.bat.in  The other batch files 
need the same
patch:

Replace:
----
set _WRAPPER_BASE=wrapper
set _WRAPPER_EXE=%_REALPATH%%_WRAPPER_BASE%-windows-x86-32.exe
if exist %_WRAPPER_EXE% goto conf
set _WRAPPER_EXE=%_REALPATH%%_WRAPPER_BASE%-windows-x86-64.exe
if exist %_WRAPPER_EXE% goto conf
set _WRAPPER_EXE=%_REALPATH%%_WRAPPER_BASE%.exe
if exist %_WRAPPER_EXE% goto conf
echo Unable to locate a Wrapper executable using any of the following names:
----
With:
----
set _WRAPPER_BASE=wrapper
set _WRAPPER_EXE=%_REALPATH%%_WRAPPER_BASE%-windows-x86-32.exe
if exist "%_WRAPPER_EXE%" goto conf
set _WRAPPER_EXE=%_REALPATH%%_WRAPPER_BASE%-windows-x86-64.exe
if exist "%_WRAPPER_EXE%" goto conf
set _WRAPPER_EXE=%_REALPATH%%_WRAPPER_BASE%.exe
if exist "%_WRAPPER_EXE%" goto conf
echo Unable to locate a Wrapper executable using any of the following names:
----

Cheers,
Leif

Patrick Kimber wrote:
> Hi
>
> Our application, which is based on the Java Service Wrapper, is installed to:
> C:\Program Files\app-name\bin\
>
> We are using the wrapper-delta-pack-3.2.0
>
> The Windows batch files, including InstallTestWrapper-NT.bat,
> UninstallTestWrapper-NT.bat and TestWrapper.bat, fail with the
> following message:
>
> Unable to locate a Wrapper executable using any of the following names:
> C:\Program Files\app-name\bin\wrapper-windows-x86-32.exe
> C:\Program Files\app-name\bin\wrapper-windows-x86-64.exe
> C:\Program Files\app-name\bin\wrapper.exe
>
> This is because the path contains spaces and the batch files do not
> enclose the path to the wrapper exe file in quotes when checking to
> see if it exists.
>
> e.g.
> if exist %_WRAPPER_EXE% goto conf
>
> can be made to work on a path with spaces by enclosing the variable in quotes:
> if exist "%_WRAPPER_EXE%" goto conf
>
> Is this how we should solve the problem.  Will the batch files be
> updated for the next release?
>
> Thanks for your help.  The wrapper is excellent.  We are very happy with it.
>
> Patrick
>   

Re: [Wrapper-user] Using JSW To Run a Java Server on a Privileged Port?

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

Jason,
    This is discussed in this feature request.
http://sourceforge.net/tracker/index.php?func=detail&aid=490806&group_id=39428&atid=425190
    If there is anything that I have overlooked, feel free to add to 
this issue.  It is
something I would like to make available, I am just not sure how.

    The problem is that the Tomcat loader binds to the port as root and 
then changes to
another user while maintaining a reference to the port.   Once the user 
has been changed,
there is of course no way to go back to being root.

    The Wrapper could do something like this once, but it would not be 
possible to recover
from failures and launch a new JVM as that would require becoming root a 
second time.

    In your case, it sounds like you want to let your live users connect 
directly to Tomcat.
I haven't used the newest version, but older versions were not really 
designed for this.
Usually, you would have Apache running and then connect to Tomcat using 
mod_jk.
This makes it possible for Tomcat to only need high ports, resolving 
this problem
completely.

Cheers,
Leif

Jason Brittain wrote:
> Hi JSW developers.
>
> I couldn't find info on your web pages / docs about whether JSW implements this
> feature, so I'm guessing it doesn't -- the ability to run a Java
> program as a non-root
> user and open privileged server ports.  For example, run Tomcat through JSW as
> user "tomcat" and still open web server port 80.
>
> The Apache Jakarta Commons Daemon jsvc binary that comes with Tomcat does
> this, but has fewer other features:
>
> http://jakarta.apache.org/commons/daemon/jsvc.html
>
> JSW doesn't do it as far as I can see, but has lots of nice service
> features that
> Tomcat users could make use of -- but most will want the port 80 capability.
>
> Have you considered adding this feature already?  I searched this mailing list
> archive and did not see it discussed.
>
> Cheers.
>
> --
> Jason Brittain
>   

[Wrapper-user] Using JSW To Run a Java Server on a Privileged Port?

[Jason B. <jas...@gm...>]

Hi JSW developers.

I couldn't find info on your web pages / docs about whether JSW implements =
this
feature, so I'm guessing it doesn't -- the ability to run a Java
program as a non-root
user and open privileged server ports.  For example, run Tomcat through JSW=
 as
user "tomcat" and still open web server port 80.

The Apache Jakarta Commons Daemon jsvc binary that comes with Tomcat does
this, but has fewer other features:

http://jakarta.apache.org/commons/daemon/jsvc.html

JSW doesn't do it as far as I can see, but has lots of nice service
features that
Tomcat users could make use of -- but most will want the port 80 capability=
.

Have you considered adding this feature already?  I searched this mailing l=
ist
archive and did not see it discussed.

Cheers.

--
Jason Brittain

[Wrapper-user] Delta Pack fails when run in a Windows folder with spaces in the path

[Patrick K. <mai...@gm...>]

Hi

Our application, which is based on the Java Service Wrapper, is installed t=
o:
C:\Program Files\app-name\bin\

We are using the wrapper-delta-pack-3.2.0

The Windows batch files, including InstallTestWrapper-NT.bat,
UninstallTestWrapper-NT.bat and TestWrapper.bat, fail with the
following message:

Unable to locate a Wrapper executable using any of the following names:
C:\Program Files\app-name\bin\wrapper-windows-x86-32.exe
C:\Program Files\app-name\bin\wrapper-windows-x86-64.exe
C:\Program Files\app-name\bin\wrapper.exe

This is because the path contains spaces and the batch files do not
enclose the path to the wrapper exe file in quotes when checking to
see if it exists.

e.g.
if exist %_WRAPPER_EXE% goto conf

can be made to work on a path with spaces by enclosing the variable in quot=
es:
if exist "%_WRAPPER_EXE%" goto conf

Is this how we should solve the problem.  Will the batch files be
updated for the next release?

Thanks for your help.  The wrapper is excellent.  We are very happy with it=
.

Patrick

Re: [Wrapper-user] Timeout/Shutdown

[Eyal Bar-I. <ey...@gm...>]

Jim,

It could be a Full GC that takes too long use the "-verbose:gc" flag to see
if it happnes when you have a Full GC

Eyal

On 4/6/06, Jim Redman <jr...@er...> wrote:
>
> We have a graphical application that we run as an .exe using the
> wrapper.  It restarts on a timeout:
>
> ERROR  | wrapper  | 2006/04/07 00:08:05 | JVM appears hung: Timed out
> waiting for signal from JVM.
> ERROR  | wrapper  | 2006/04/07 00:08:05 | JVM did not exit on request,
> terminated
>
> I don't really case about the wrapper timeout, the application is
> interactive and the user can take care of real problems, but I'm
> wondering what we're doing that's causing a problem.
>
> Are the "pings" sent from the Java Event thread?    The application
> could use a little optimization and is a memory hog.  We tend to go into
> phases in the program where we'll take 100% CPU time, such as compiling
> applications, so we get, eg this:
>
> INFO   | wrapper  | 2006/04/06 23:32:15 | Wrapper Process has not
> received any CPU time for 141 seconds.  Extending timeouts.
>
> but even during this the screen is repainting (usually and slowly).
>
> Not too important, but any thoughts appreciated.
>
> 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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] restart tuning

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

Leif and David - thanks for the quick replies.

Leif Mortenson wrote:
> In most cases, setting a hard number of restarts of 5 would be bad for 
> an application
> that crashes once in a while.  It would restart 5 times over say a 
> month and then
> suddenly fail to come up a 6th time.  This is why the successful 
> invocation time
> exists to allow this counter the be reset.
I understand this. In my case, however, I don't want to allow any 
crashes of the application. In any case, I'd like to know of these 
crashes, so I could fix the bugs causing them. This is especially 
importance in a service version, where people are likely to forget that 
the application is even running, and so wouldn't notice frequent 
crashes, as long as the application restarts.

I have no problem using the workaround of setting a large value for max 
invocations, if you don't think this could interest other people.

Cheers,
Anat

[Wrapper-user] Timeout/Shutdown

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

We have a graphical application that we run as an .exe using the 
wrapper.  It restarts on a timeout:

ERROR  | wrapper  | 2006/04/07 00:08:05 | JVM appears hung: Timed out 
waiting for signal from JVM.
ERROR  | wrapper  | 2006/04/07 00:08:05 | JVM did not exit on request, 
terminated

I don't really case about the wrapper timeout, the application is 
interactive and the user can take care of real problems, but I'm 
wondering what we're doing that's causing a problem.

Are the "pings" sent from the Java Event thread?    The application 
could use a little optimization and is a memory hog.  We tend to go into 
phases in the program where we'll take 100% CPU time, such as compiling 
applications, so we get, eg this:

INFO   | wrapper  | 2006/04/06 23:32:15 | Wrapper Process has not 
received any CPU time for 141 seconds.  Extending timeouts.

but even during this the screen is repainting (usually and slowly).

Not too important, but any thoughts appreciated.

Jim

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

Re: [Wrapper-user] restart tuning

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

Anat Halpern wrote:
> Yeah, I can set a very long time, no problem, and also using 0 as 
> indefinite time should work, but this looks more like a workaround 
> (which will work fine for now).
> I would have expected the wrapper to count the number of abnormal 
> terminations, regardless of the run time before this crash. BTW, this 
> is what I understood from the docs. If for example, an application 
> analyzes an input file and crashes on a specific input, (let's say 
> near the end of the file), then it will crash continuously.
That is why there is the max invocations.   It defaults to a value 
larger than 1 to support
port binding problems on solaris systems where a port could fail to bind 
the first few
invocations and then succeed after the 4th restart.  If tomcat crashes, 
its ports may
remain bound for 2 minutes and prevent future restarts.

In most cases, setting a hard number of restarts of 5 would be bad for 
an application
that crashes once in a while.  It would restart 5 times over say a month 
and then
suddenly fail to come up a 6th time.  This is why the successful 
invocation time
exists to allow this counter the be reset.

Cheers,
Leif

Re: [Wrapper-user] restart tuning

[<da...@sm...>]

On the other hand, I can see also where you would like the Wrapper to go.

For Server applications, where you want the maximum availability and
reliability, you want the wrapper to ALWAYS restart the app when it gets into
trouble.
For your app and others that match the requirement, you want less availability
and reliability, and you want the wrapper to restart the app up to X number of
times when the app has actually started. If it still is misbehaving, then just
don't try to run the app anymore.

Like I said in my previous email, Wrapper is designed more to deal with the
first kind, but I do see usefulness in the second type.

What do you think Leif?

David Hayes

Quoting Anat Halpern <an...@en...>:

> Yeah, I can set a very long time, no problem, and also using 0 as 
> indefinite time should work, but this looks more like a workaround 
> (which will work fine for now).
> I would have expected the wrapper to count the number of abnormal 
> terminations, regardless of the run time before this crash. BTW, this 
> is what I understood from the docs. If for example, an application 
> analyzes an input file and crashes on a specific input, (let's say 
> near the end of the file), then it will crash continuously.
>
> Cheers,
> Anat
>
> Leif Mortenson wrote:
>> 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
>>
>>
>>
>> -------------------------------------------------------
>> 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.
>
>
>
> -------------------------------------------------------
> 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] restart tuning

[<da...@sm...>]

This is a difficult one to gauge from the Wrappers perspective, and is 
entirely
dependant upon the application it is wrapping.

The way that the wrapper is set up is to deal with applications that "can" get
themselves into a spot of bother, not really "always will". It I am 
guessing is
designed to cater for those strange errors that sneak into an application that
you don't see normally, that hang the app, but the next time you run
mysteriously go away.

One thing, why don't you set the set the startup time like Leif says to be
either 0 or a very large time (like 5 years), and constantly call
signalStarting(...), and then when the application has done everything you
wanted it to do successfully, call signalStarted(). That way if your app
crashes whilst starting up, it should get counted against the max failed
invocations. What appears to be happening, is the Wrapper has considered your
app started, and thinks "Oh, it had a spot of bother during the regular
running, lets restart it to keep the service it provides alive as much as
possible".

Hope this helps Anat,

David Hayes

Quoting Anat Halpern <an...@en...>:

> Yeah, I can set a very long time, no problem, and also using 0 as 
> indefinite time should work, but this looks more like a workaround 
> (which will work fine for now).
> I would have expected the wrapper to count the number of abnormal 
> terminations, regardless of the run time before this crash. BTW, this 
> is what I understood from the docs. If for example, an application 
> analyzes an input file and crashes on a specific input, (let's say 
> near the end of the file), then it will crash continuously.
>
> Cheers,
> Anat
>
> Leif Mortenson wrote:
>> 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
>>
>>
>>
>> -------------------------------------------------------
>> 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.
>
>
>
> -------------------------------------------------------
> 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] restart tuning

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

Yeah, I can set a very long time, no problem, and also using 0 as 
indefinite time should work, but this looks more like a workaround 
(which will work fine for now).
I would have expected the wrapper to count the number of abnormal 
terminations, regardless of the run time before this crash. BTW, this is 
what I understood from the docs. If for example, an application analyzes 
an input file and crashes on a specific input, (let's say near the end 
of the file), then it will crash continuously.

Cheers,
Anat

Leif Mortenson wrote:
> 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
>
>
>
> -------------------------------------------------------
> 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.