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

[Wrapper-user] RE: No args wrapper startup

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

Sal,

Beyond the obvious observation that batch files are ugly, we have at 
least on sitution where a batch file will not work.  The OPC standard, 
which we support, mandates that one of the registry keys associated 
with an application is an executable, not a batch file.

In our case, it is the end users choice whether to install a service or 
not.  For some customers the applications will not run as a service, 
the application will grab the executable from the registry and run it 
and check that the application is still alive.  Others want a 
service.   Some want a real user interface, etc. etc. Hence the 
attraction of the wrapper, it does all these things.

> From: Sal Ingrilli <sal@sy...>
> RE: No args wrapper startup
> 2003-09-11 10:26

> i would definitely use the default "wrapper.conf" file name and 
> location if its "../conf/wrapper.conf" and it is relative to wrapper.
> exe.

In this case, you could only have one application per directory.  Might 
not be a restriction in your case, but are you sure you want to impose 
it upon everyone? 
> i disagree with you on the default argument because the wrapper is a 
> service wrapper. i think that the default option should be to install 
> and start the service, as in "wrapper -it" i think that if you 
> wantthe default option to be "-c" you should create yourself a batch 
> filetorun your app.

If there's no interest, I'm going to hack this for myself.  If there's 
interest then I don't mind making a more general solution.  For 
example, double-clicking app.exe could read app.conf and find out what 
it's suppose to do next (install as service, run in console, etc.).  
That is, the default command line options could be encoded in the 
configuration file.

However it seems that there's _almost_ a mechanism similar to this in 
the build scripts, and I would want to re-invent something that already 
has a good solution.

Jim
PS There seems to be some disagreement between my mailer (Balsa) and 
the list server as to who I am, so my apologies for the ugly formatting.

> -----Original Message-----
> From: wrapper-user-admin@li...
> [mailto:wrapper-user-admin@li...]On Behalf Of Jim Redman
> Sent: Thursday, September 11, 2003 6:52 AM
> To: wrapper-user@li...
> Subject: [Wrapper-user] No args wrapper startup
> 
> I'd like to use the wrapper to start a console application.  But 
> Ineed a single executable that the user can click on, that is, no 
> argspassed to the application.
> 
> Is this possible without modifications to the c source?
> 
> If not, is anyone else interested in this?  My idea would be to have
> double-clicking on app.exe be the same as "app -c app.conf" if app.
> conf exists.
> 


-- 

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

RE: [Wrapper-user] No args wrapper startup

[Sal I. <sal...@sy...>]

i would definitely use the default "wrapper.conf" file name and location if
its "../conf/wrapper.conf" and it is relative to wrapper.exe.

i disagree with you on the default argument because the wrapper is a service
wrapper.
i think that the default option should be to install and start the service,
as in "wrapper -it"

i think that if you want the default option to be "-c" you should create
yourself a batch file to run your app.

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Jim Redman
Sent: Thursday, September 11, 2003 6:52 AM
To: wra...@li...
Subject: [Wrapper-user] No args wrapper startup




I'd like to use the wrapper to start a console application.  But I need
a single executable that the user can click on, that is, no args passed
to the application.

Is this possible without modifications to the c source?

If not, is anyone else interested in this?  My idea would be to have
double-clicking on app.exe be the same as "app -c app.conf" if app.conf
exists.
Jim

PS Apologies if this is a repeat - I didn't get a copy of the original
and it's not in the archive.

--

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Single wrapper release possible?

[<da...@ix...>]

In article <106...@we...>,
Fredrik Israelsson  <wra...@li...> wrote:
>I don't question writing the wrapper in C. My question is more like why one 
>cannot make one wrapper release with binaries needed for all platforms. I mean, 
>storage space for the few MB:s needed is not a problem theese days.

I'm of two minds about this myself.

After all, the JRE doesn't come with only one package; you have to download
a different package for each arch.  Ok, well, Sun's is like that; I have no
experience with any others, so maybe they do.

But on the other hand, personally I package my app separately with all
wrapper stuff appropriate for supports platforms, and distribute all addons
(JDK, 3rd party libs, etc) as a second package, which is platform specific.

Now, currently we only support Linux and Win32, so there are no conflicts
with wrapper and wrapper.exe and wrapper.dll and libwrapper.so.

But, what if I want to package another unix like platform that also uses
.so?  Then it becomes a bit trickier.

Sure, I could have wrapper.Linux and wrapper.FreeBSD and modify wrapper.sh
to call wrapper.`uname -s` or something.  But that doesn't solve the
dynamically loaded library issue.

I think a nice enhancement would be if the call to System.loadLibrary()
first tried "wrapper" and if that didn't work, try "wrapper.arch" or
something.  I'm no Java expert, but it looks like the java property os.name
might be appropriate?  Actually, may be a good idea to use os.name +
os.arch to correctly support same OS on multiple platforms.  Linux and
FreeBSD, for example, both work on non-i386 arch.  And if you're supporting
FreeBSD, which has to build their own java from Sun's source anyway, might
as well support them compiling it on a myriad of platforms.

One reason this really concerns me is that the developers here like to run
the same compiled code on two machines to test communications.  Sometimes
those two machines are different OSes.  We're lucky now that Linux and
Win32 can coexist.  But if we start supporting other platforms, it becomes
more of an issue.

Anyway, just my thoughts on the matter.

Cheers,
mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Wrapper-user] No args wrapper startup

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

I'd like to use the wrapper to start a console application.  But I need 
a single executable that the user can click on, that is, no args passed 
to the application.

Is this possible without modifications to the c source?

If not, is anyone else interested in this?  My idea would be to have 
double-clicking on app.exe be the same as "app -c app.conf" if app.conf 
exists.  
Jim

PS Apologies if this is a repeat - I didn't get a copy of the original 
and it's not in the archive.

-- 

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

Re: [Wrapper-user] Single wrapper release possible?

[Fredrik I. <fre...@st...>]

Citerat fr=E5n  Leif Mortenson <le...@ta...>:

> Fredrik,
>     The Wrapper provides several functions which would be impossible to
>=20
> implement in
> pure Java.  These include interacting with the NT service manager on=20
> Windows, low
> level process control on the UNIX platforms, and the ability to trap=20
> system signals on
> all platforms.
>     Another reason for writing the Wrapper in C was to make it light=20
> weight.  One of
> the main reasons that I wrote the Java Service Wrapper in the first=20
> place was because
> I was having problems with unreliable JVMs that kept crashing on me. Th=
e
>
> Wrapper,
> as you may know, has the ability to monitor the Java process and restar=
t
>=20
> it in the
> event of a hang or crash, with very little downtime.  Java is great, bu=
t
>=20
> it also has a
> very large memory footprint and I wanted the Wrapper to be as small as
>=20
> possible.
>     Perl could have been another option on UNIX systems, but that would
>=20
> have placed
> a requirement on Perl which I did not want to add.  On Windows, C was=20
> the only real
> choice.  The majority of the Wrapper's C code is cross platform, so C=20
> became the
> final language of choice.
>=20

I don't question writing the wrapper in C. My question is more like why o=
ne=20
cannot make one wrapper release with binaries needed for all platforms. I=
 mean,=20
storage space for the few MB:s needed is not a problem theese days.

>     Your main question was about the wrapper.conf file and having to=20
> create a new conf
> file for each platform.   This should actually not be necessary.   The
>
> Wrapper was
> specifically designed to make the wrapper.conf file portable.  If you=20
> use forward slashes
> in all paths, and use relative paths as much as possible then your conf
>
> file will work
> as is no matter what platform the Wrapper is run on.   There are of=20
> course some
> properties which are ignored on UNIX or Windows platforms.  These=20
> include the
> NT service properties, which are obviously only used under Windows, and
> the
> daemonize property which is only used on UNIX.
>=20
>     Integrating the Wrapper into your application does have the drawbac=
k
>=20
> of requiring
> you to start making platform specific binary releases of your=20
> application.  But this
> is only to include the Wrapper binary code.  All of your code, includin=
g
> the
> wrapper.conf file will be 100% platform independent.
>     For customer applications, I usually like to avoid problems caused
>=20
> by the customer
> running a different JRE by simply including a JRE in my application=20
> release.  This
> obviously increases the release size, but so far it has been well worth
> it.
>=20
>     The following is a directory structure that I typically use for Jav=
a
>=20
> applications.
> .../app/bin
> .../app/conf
> .../app/lib
> .../app/jre
> .../app/<etc>
>=20
>     The Wrapper.exe, App.bat, InstallApp-NT.bat,=20
> UninstallApp-NT.bat(Windows)
> or wrapper, app.sh(wrapper) files all go into the bin directory.
>     The wrapper.conf file goes into the conf directory along with the=20
> rest of the
> application's configuration files.
>     The Wrapper.dll (Windows), libwrapper.so(UNIX),=20
> libwrapper.jnilib(MacOSX)
> and wrapper.jar files all go into the lib directory along with the rest
>=20
> of the application's
> jar files and any other native libraries.
>     The JRE is copied into the jre directory etc.
>     Then in the wrapper.conf file, and in your application, all paths=20
> are relative to the bin
> directory.  This will make your application very portable.
>=20
> Let me know if you have any further questions or suggestions.
>=20
> Cheers,
> Leif

If one includes the jre, I see a problem with my idea. The installation w=
ould=20
become very large with 5-10 jre:s for different platforms.=20

In February I wrote an application that I wanted to be able to run on Win=
dows,=20
Linux and Solaris. I downloaded the wrapper for those platforms and manua=
lly=20
merged the files into one release. That meant renaming the binaries "real=
path",=20
"testwrapper" and "wrapper", as those are identical in name on Linux and=20
Solaris, and to manually go through the installation scripts making sure =
that=20
they called the correct file. The problem is that doing this manually for=
 each=20
new version of wrapper, I know I am going to make a misstake sooner or la=
ter.
Also, there was no real reason why my code would not run on aix our hpux,=
 but I=20
was to lazy to include those as I thougt it was not likely that anyone wo=
uld run=20
it on those platforms.

If all platform specific files got a name that included the platform name=
, then=20
only one wrapper distribution would be necessary, instead of 8. If one=20
absolutely do not want support for more than one platform, one can delete=
 all=20
files with a name including another platform.=20

/Fredrik

> Fredrik Israelsson wrote:
>=20
> >Hello
> >First of all, I want to thank you for wrapper, giving functionality
> that should=20
> >have been supported by Sun a long time ago IMHO.
> >
> >I have a theoretical question. What is the main problem(s) that keeps
> wrapper=20
> >from becoming a single release (with a single config-file) for all
> platforms=20
> >supported?
> >
> >One of my main arguments for using java is platform portability. When =
I
> make a=20
> >service/daemon, I would like it to be able to run on as many platforms
> as=20
> >possible, out of the box, without having to maintain several config
> files etc.
> >
> >Maybe this is possible already? I am not a wrapper expert, but then,
> why are=20
> >there different downloads available?
> >
> >Regards
> >Fredrik Israelsson
> > =20
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>=20

Re: [Wrapper-user] Single wrapper release possible?

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

Fredrik,
    The Wrapper provides several functions which would be impossible to 
implement in
pure Java.  These include interacting with the NT service manager on 
Windows, low
level process control on the UNIX platforms, and the ability to trap 
system signals on
all platforms.
    Another reason for writing the Wrapper in C was to make it light 
weight.  One of
the main reasons that I wrote the Java Service Wrapper in the first 
place was because
I was having problems with unreliable JVMs that kept crashing on me. The 
Wrapper,
as you may know, has the ability to monitor the Java process and restart 
it in the
event of a hang or crash, with very little downtime.  Java is great, but 
it also has a
very large memory footprint and I wanted the Wrapper to be as small as 
possible.
    Perl could have been another option on UNIX systems, but that would 
have placed
a requirement on Perl which I did not want to add.  On Windows, C was 
the only real
choice.  The majority of the Wrapper's C code is cross platform, so C 
became the
final language of choice.

    Your main question was about the wrapper.conf file and having to 
create a new conf
file for each platform.   This should actually not be necessary.   The 
Wrapper was
specifically designed to make the wrapper.conf file portable.  If you 
use forward slashes
in all paths, and use relative paths as much as possible then your conf 
file will work
as is no matter what platform the Wrapper is run on.   There are of 
course some
properties which are ignored on UNIX or Windows platforms.  These 
include the
NT service properties, which are obviously only used under Windows, and the
daemonize property which is only used on UNIX.

    Integrating the Wrapper into your application does have the drawback 
of requiring
you to start making platform specific binary releases of your 
application.  But this
is only to include the Wrapper binary code.  All of your code, including the
wrapper.conf file will be 100% platform independent.
    For customer applications, I usually like to avoid problems caused 
by the customer
running a different JRE by simply including a JRE in my application 
release.  This
obviously increases the release size, but so far it has been well worth it.

    The following is a directory structure that I typically use for Java 
applications.
.../app/bin
.../app/conf
.../app/lib
.../app/jre
.../app/<etc>

    The Wrapper.exe, App.bat, InstallApp-NT.bat, 
UninstallApp-NT.bat(Windows)
or wrapper, app.sh(wrapper) files all go into the bin directory.
    The wrapper.conf file goes into the conf directory along with the 
rest of the
application's configuration files.
    The Wrapper.dll (Windows), libwrapper.so(UNIX), 
libwrapper.jnilib(MacOSX)
and wrapper.jar files all go into the lib directory along with the rest 
of the application's
jar files and any other native libraries.
    The JRE is copied into the jre directory etc.
    Then in the wrapper.conf file, and in your application, all paths 
are relative to the bin
directory.  This will make your application very portable.

Let me know if you have any further questions or suggestions.

Cheers,
Leif

Fredrik Israelsson wrote:

>Hello
>First of all, I want to thank you for wrapper, giving functionality that should 
>have been supported by Sun a long time ago IMHO.
>
>I have a theoretical question. What is the main problem(s) that keeps wrapper 
>from becoming a single release (with a single config-file) for all platforms 
>supported?
>
>One of my main arguments for using java is platform portability. When I make a 
>service/daemon, I would like it to be able to run on as many platforms as 
>possible, out of the box, without having to maintain several config files etc.
>
>Maybe this is possible already? I am not a wrapper expert, but then, why are 
>there different downloads available?
>
>Regards
>Fredrik Israelsson
>  
>

[Wrapper-user] Single wrapper release possible?

[Fredrik I. <fre...@st...>]

Hello
First of all, I want to thank you for wrapper, giving functionality that should 
have been supported by Sun a long time ago IMHO.

I have a theoretical question. What is the main problem(s) that keeps wrapper 
from becoming a single release (with a single config-file) for all platforms 
supported?

One of my main arguments for using java is platform portability. When I make a 
service/daemon, I would like it to be able to run on as many platforms as 
possible, out of the box, without having to maintain several config files etc.

Maybe this is possible already? I am not a wrapper expert, but then, why are 
there different downloads available?

Regards
Fredrik Israelsson

RE: [Wrapper-user] Wrapper configuration problems

[Max S. <MSt...@li...>]

Leif,

  You are the best. Thanks a lot.

Max

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Friday, September 05, 2003 10:58 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Wrapper configuration problems

Max,
Starting with version 3.0.4, you can use the Wrapper to start and stop your
service. The Wrapper's method is much more reliable than the "net start x"
command when the service takes a long time to start or stop. And if you use
the Wrapper, you will never have problems like you just had because the only
place the service name exists is in the wrapper.conf file.

See the section on Launching the Wrapper under Windows for more details.
http://wrapper.tanukisoftware.org/doc/english/launch-win.html

Basically, you would modify the batch file like this:
---
:startup
"%_APP_HOME%\bin\Wrapper.exe" -i %_WRAPPER_CONF%
if not errorlevel 1 goto end
pause

:end
---
Becomes:
---
:startup
"%_APP_HOME%\bin\Wrapper.exe" -i %_WRAPPER_CONF%
if not errorlevel 1 goto startup2
pause

:startup2
"%_APP_HOME%\bin\Wrapper.exe" -t %_WRAPPER_CONF%
if not errorlevel 1 goto end
pause

:end
---

Glad you got it working.

Cheers,
Leif

Max Stolyarov wrote:

>Leif,
>
>  Sorry of all the confusion I caused with this e-mail thread. After
careful
>testing yesterday and review of my code, I determined that was an error in
>my coding and nothing to do with the wrapper. What happened, is I modified
>the bat file that shipped with wrapper to automatically start the service
>after it is installed, but when I modified the service name in the wrapper
>Config file I forgot to update the service name in the installation bat
file
>where I tried to start the service with a 'net start' command. That was the
>reason why any time I tried to start the service it would give me an error,
>service name is invalid.... Sorry again. Thanks for all of your time and
>great explanations.
>
>Max
>
>  
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Wrapper configuration problems

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

Max,
Starting with version 3.0.4, you can use the Wrapper to start and stop your
service. The Wrapper's method is much more reliable than the "net start x"
command when the service takes a long time to start or stop. And if you use
the Wrapper, you will never have problems like you just had because the only
place the service name exists is in the wrapper.conf file.

See the section on Launching the Wrapper under Windows for more details.
http://wrapper.tanukisoftware.org/doc/english/launch-win.html

Basically, you would modify the batch file like this:
---
:startup
"%_APP_HOME%\bin\Wrapper.exe" -i %_WRAPPER_CONF%
if not errorlevel 1 goto end
pause

:end
---
Becomes:
---
:startup
"%_APP_HOME%\bin\Wrapper.exe" -i %_WRAPPER_CONF%
if not errorlevel 1 goto startup2
pause

:startup2
"%_APP_HOME%\bin\Wrapper.exe" -t %_WRAPPER_CONF%
if not errorlevel 1 goto end
pause

:end
---

Glad you got it working.

Cheers,
Leif

Max Stolyarov wrote:

>Leif,
>
>  Sorry of all the confusion I caused with this e-mail thread. After careful
>testing yesterday and review of my code, I determined that was an error in
>my coding and nothing to do with the wrapper. What happened, is I modified
>the bat file that shipped with wrapper to automatically start the service
>after it is installed, but when I modified the service name in the wrapper
>Config file I forgot to update the service name in the installation bat file
>where I tried to start the service with a 'net start' command. That was the
>reason why any time I tried to start the service it would give me an error,
>service name is invalid.... Sorry again. Thanks for all of your time and
>great explanations.
>
>Max
>
>  
>

RE: [Wrapper-user] Wrapper configuration problems

[Max S. <MSt...@li...>]

Leif,

  Sorry of all the confusion I caused with this e-mail thread. After careful
testing yesterday and review of my code, I determined that was an error in
my coding and nothing to do with the wrapper. What happened, is I modified
the bat file that shipped with wrapper to automatically start the service
after it is installed, but when I modified the service name in the wrapper
Config file I forgot to update the service name in the installation bat file
where I tried to start the service with a 'net start' command. That was the
reason why any time I tried to start the service it would give me an error,
service name is invalid.... Sorry again. Thanks for all of your time and
great explanations.

Max

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Friday, September 05, 2003 3:50 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Wrapper configuration problems

Max,
Could you be more specific about what properties you modified and what
registry entries you had to manually delete? Also can you verify that you
are using the batch files shipped with the Wrapper to install and remove the
service?
Also what is the exact "problem" that you are having installing the
application as a service. Is it that your service name is invalid? If so
what
is the service name that you are trying to set?

I went back and retested the Wrapper's handling of the registry. When
you install the Wrapper, it adds an entry at the following location:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{servicename}

Then when you remove the service, the above entry is removed completely.
No garbage is left behind in the Registry. Rare for a "Windows program :-)

One exception is if you are logging to the Event Log. If and only if you
have the wrapper.syslog.loglevel property set to a level other than NONE,
a registry entry is added at the following location:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\{
servicename}
This registry entry is created even if the application is run only as a
console
app. The registry entry is never deleted by the Wrapper as doing so would
cause the EventLog application to popup errors when attempting to view the
logged entries.

I am trying to get version 3.0.5 out the door and want to make sure that
I don't have an outstanding bug here.

Cheers,
Leif

Max Stolyarov wrote:

>Leif,
>
>    Thanks for the reply. I understand what you are saying and after more
>testing that I did yesterday, I am starting to feel that the configuration
>file is not an issue here. At this stage of testing I feel that the problem
>that I am experiencing has something to do with deployment and removal of
NT
>services. This is what I have done:
>
>1. I modified my wrapper Config properties (NT service properties).
>2. Ran your bat file to deploy the wrapper and install the service.
>3. Ran another bat file to stop and remove the service.
>4. Modified NT properties again in the wrapper configuration file
>5. Ran a bat file to deploy a service. At this point, I get an exception in
>the command windows that informs me that the service name is invalid.
>6. I poked around in the registry, and I feel that the bat file that I use
>to stop and remove the NT service is not doing a good job in removing the
>service entries from the registry. Am saying this because, when I removed
>couple of the registry entries related to the first service, I was able to
>deploy the new service. I will let you know, with more testing what
registry
>key remain and needs to be removed. If you have some idea what I need to
try
>please let me know. Thanks
>
>Thanks
>
>Max
>  
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Wrapper configuration problems

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

Max,
Could you be more specific about what properties you modified and what
registry entries you had to manually delete? Also can you verify that you
are using the batch files shipped with the Wrapper to install and remove the
service?
Also what is the exact "problem" that you are having installing the
application as a service. Is it that your service name is invalid? If so
what
is the service name that you are trying to set?

I went back and retested the Wrapper's handling of the registry. When
you install the Wrapper, it adds an entry at the following location:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{servicename}

Then when you remove the service, the above entry is removed completely.
No garbage is left behind in the Registry. Rare for a "Windows program :-)

One exception is if you are logging to the Event Log. If and only if you
have the wrapper.syslog.loglevel property set to a level other than NONE,
a registry entry is added at the following location:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\{servicename}
This registry entry is created even if the application is run only as a
console
app. The registry entry is never deleted by the Wrapper as doing so would
cause the EventLog application to popup errors when attempting to view the
logged entries.

I am trying to get version 3.0.5 out the door and want to make sure that
I don't have an outstanding bug here.

Cheers,
Leif

Max Stolyarov wrote:

>Leif,
>
>    Thanks for the reply. I understand what you are saying and after more
>testing that I did yesterday, I am starting to feel that the configuration
>file is not an issue here. At this stage of testing I feel that the problem
>that I am experiencing has something to do with deployment and removal of NT
>services. This is what I have done:
>
>1. I modified my wrapper Config properties (NT service properties).
>2. Ran your bat file to deploy the wrapper and install the service.
>3. Ran another bat file to stop and remove the service.
>4. Modified NT properties again in the wrapper configuration file
>5. Ran a bat file to deploy a service. At this point, I get an exception in
>the command windows that informs me that the service name is invalid.
>6. I poked around in the registry, and I feel that the bat file that I use
>to stop and remove the NT service is not doing a good job in removing the
>service entries from the registry. Am saying this because, when I removed
>couple of the registry entries related to the first service, I was able to
>deploy the new service. I will let you know, with more testing what registry
>key remain and needs to be removed. If you have some idea what I need to try
>please let me know. Thanks
>
>Thanks
>
>Max
>  
>

Re: [Wrapper-user] Newbie (?) Questions

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

Georg,
Your last request to be able to set the ping interval has also been 
added for version 3.0.5.
The property is called wrapper.ping.interval.

Cheers,
Leif

Georg Schmid wrote:

> 3) I could not find a parameter to control the ping frequency (not the 
> timeout). The ping slows down the application, and for a server, that 
> should be running for half a year a ping every 30 seconds or similar 
> would be good enough.

RE: [Wrapper-user] Wrapper configuration problems

[Max S. <MSt...@li...>]

Leif,

    Thanks for the reply. I understand what you are saying and after more
testing that I did yesterday, I am starting to feel that the configuration
file is not an issue here. At this stage of testing I feel that the problem
that I am experiencing has something to do with deployment and removal of NT
services. This is what I have done:

1. I modified my wrapper Config properties (NT service properties).
2. Ran your bat file to deploy the wrapper and install the service.
3. Ran another bat file to stop and remove the service.
4. Modified NT properties again in the wrapper configuration file
5. Ran a bat file to deploy a service. At this point, I get an exception in
the command windows that informs me that the service name is invalid.
6. I poked around in the registry, and I feel that the bat file that I use
to stop and remove the NT service is not doing a good job in removing the
service entries from the registry. Am saying this because, when I removed
couple of the registry entries related to the first service, I was able to
deploy the new service. I will let you know, with more testing what registry
key remain and needs to be removed. If you have some idea what I need to try
please let me know. Thanks

Thanks

Max

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...] 
Sent: Wednesday, September 03, 2003 1:54 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Wrapper configuration problems

Max,
Originally, the Wrapper's property file worked almost exactly like the
java.util.Properties class. However there have been a couple features which
have caused it to diverge slightly.

1) The ability to set environment variables. It is possible to define a
property
like the following:
set.JAVA_HOME=../jre
This value can then be used as follows:
wrapper.java.command=%JAVA_HOME%/bin/java
Environment variables in the properties file are expanded as the
properties are
loaded from the file. For this reason, it is necessary to define the
environment
variable at a point in the file before it is used.

2) Include files. It is possible to specify other properties files that
will be recursively
read in at the point that they are declared. Properties defined in the
include files
follow the above rule.

3) I think this is the same as the java Properties class, but any
properties that are
defined more than once will end up with the value declared last.

Once all of the properties are loaded however, they are accessed as a
hash map so
there should be absolutely no further dependency on the order of the
properties in
the file.

Would it be possible for you post exactly what properties are causing you
problems? What you are describing, with the above exceptions, should not be
happening, so I would like to see what you are referring to.

Cheers,
Leif

Max Stolyarov wrote:

> Leif,
>
> I wrote a code to dynamically modify wrapper.conf file in order to on
> the fly change NT service's name, display name, and service
> description parameters. When I analyzed this file, I though that this
> is a simple properties file that you probably read and then apply
> internally. Because of this, I thought that the order in which
> parameters appear in the file does not matter. Apparently I thought
> wrong. In my file, parameters were in different order then in your
> file, and when I tried to install the wrapper and run my application
> as a service, it did not; the NT service did not start. In order to
> trouble shoot the problem, I replaced my file with your wrapper.conf
> file, tried to load and start the service again and it worked. (Number
> of parameters in each file is the same). Therefore, I feel that for
> some reason or not, the order in which parameters appear in your
> wrapper.conf file is very important. Can you please let me know why
> did you handle properties in such a way? Also, if this is not
> something you planned for can you please update file that reads
> configuration properties, to first read it and then apply them, so
> that the order in which they appear in the Config file is not
> important. Thanks in advance.
>
> Max
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] WrapperManager: jmx interface

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

Sal,
    I liked this idea.  It has been implemented and will be in the 3.0.5 
release.
I wrote up some docs for the JBoss case, but still need to do so for the
Sun JMX RI example.  If you have any ideas for the docs, please let me know.

    The new code and existing docs are now all checked into CVS, if you 
want to
try checking them out and do some testing, I would appreciate it.  Also 
if you have
any comments on the published API, before the release is the time to get any
changes in.  Note that the public CVS is currently running 24 hours behind.
    I also placed a pair of source snapshots up on my server if you prefer.
(They are not 24 hours behind :-)
http://wrapper.tanukisoftware.org/tmp/wrapper_3.0.5b_src_with_doc_src.tar.gz
http://wrapper.tanukisoftware.org/tmp/wrapper_3.0.5b_src_with_doc_src.zip

    The new docs are at /doc/english/jmx.html

Cheers,
Leif

Sal Ingrilli wrote:

>Leif:
>
>I saw the previous posting on WrapperActionServer and find this to be
>relevant.
>
>We all know that one of the most important features of the wrapper is to
>dump threads.
>This is especially useful when running as a service, otherwise you basically
>can't do it (1).
>
>But how do you tell the wrapper to dump threads?  I was faced with this
>issue before I had the wrapper server came about.... so here is what I did.
>
>I developed a jmx-mbean that proxies calls to the WrapperManager.  I chose
>to write a jmx-mbean in order to code this only once and be able to deploy
>it to different environments.
>
>The mbean is made of these 2 java files, which need to be located in the
>same directory (2).
>
>[WrapperManagerMBean.java]
>package com.syncvoice.commons.silveregg.wrapper.jmx;
>public interface WrapperManagerMBean {
>  String getBuildTime ();
>  int getJVMId ();
>  String getVersion ();
>  boolean getHasShutdownHookBeenTriggered ();
>  boolean isControlledByNativeWrapper ();
>  boolean isDebugEnabled ();
>  boolean isLaunchedAsService ();
>
>  void restart ();
>  void requestThreadDump ();
>}
>
>[WrapperManager.java]
>package com.syncvoice.commons.silveregg.wrapper.jmx;
>import com.syncvoice.commons.silveregg.wrapper.jmx.WrapperManagerMBean;
>public class WrapperManager implements WrapperManagerMBean {
>
>  public String getBuildTime () { return
>org.tanukisoftware.wrapper.WrapperManager.getBuildTime (); }
>  public int getJVMId () { return
>org.tanukisoftware.wrapper.WrapperManager.getJVMId (); }
>  public String getVersion () { return
>org.tanukisoftware.wrapper.WrapperManager.getVersion (); }
>  public boolean getHasShutdownHookBeenTriggered () { return
>org.tanukisoftware.wrapper.WrapperManager.hasShutdownHookBeenTriggered (); }
>  public boolean isControlledByNativeWrapper () { return
>org.tanukisoftware.wrapper.WrapperManager.isControlledByNativeWrapper (); }
>  public boolean isDebugEnabled () { return
>org.tanukisoftware.wrapper.WrapperManager.isDebugEnabled (); }
>  public boolean isLaunchedAsService () { return
>org.tanukisoftware.wrapper.WrapperManager.isLaunchedAsService (); }
>
>  public void restart () { org.tanukisoftware.wrapper.WrapperManager.restart
>(); }
>  public void requestThreadDump () {
>org.tanukisoftware.wrapper.WrapperManager.requestThreadDump (); }
>}
>
>As you can see to write an mbean all you do is write an interface and
>implement it.
>No libraries to import and no custom interfaces to implement.
>The mbean i developed is nothing but a proxy into the WrapperManager.
>
>Now all you do is add a couple lines of configuration to your jmx-aware
>application, and you can point a browser to
>http://localhost/jmx-console (for JBoss)
>or
>http://localhost:8082 (default jmx listening port when using the sun jmx-ri)
>
>You'll get a UI that allows you to look at all the mbeans.
>For each mbean, you can see its attributes, which are any mbean functions
>that starts with get ().
>For each mbean, you can invoke its operations, which are any non-get*/set*
>method.
>
>But how do you publish an mbean in a jmx-aware application?
>In a JBoss environment, for example, take the following file and put it in
>the JBoss deploy folder (3).
>[wrapper-service.xml]
><?xml version="1.0" encoding="UTF-8"?>
><!DOCTYPE server>
><server>
><classpath archives="wrapper.jar" codebase="../../lib"/>
><mbean code="com.syncvoice.commons.silveregg.wrapper.jmx.WrapperManager"
>name="Adaptor:protocol=SilverEggWrapper"/>
></server>
>
>In JBoss, this file represents a service, and JBoss will hot-deploy it. Now
>to test it:
>1. point a browser to http://localhost/jmx-console
>2. click on the wrapper mbean
>3. click "requestThreadDump"
>4. Look into jboss_home/logs/wrapper.log for your thread dump!
>
>In addition to the HTTP based interface, there are a ton of other
>already-built interfaces, such as SNMP, sockets, SOAP, RMI, JMS, etc, which
>allow you to invoke mbean methods, which means that you can get to the
>wrapper manager from just as many different places.
>So now, simply by providing an mbean for the wrapper manager, i could do
>crazy things such as have my site monitoring software issue a wrapper
>restart through the RMI interface.
>
>Leif, if you want to add this functionality, i'll gladly test it out for
>you.
>
>Sal.
>
>(1) Actually, you kind of can: some people use nohup in unix..., but you
>gotta know the side effects.....
>(2) I developed this when the wrapper was still in the "silveregg" package.
>(3) wrapper.exe goes in jboss/bin, wrapper.dll and wrapper.jar go in
>jboss/lib
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
>at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

Re: [Wrapper-user] Newbie (?) Questions

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

Georg Schmid wrote:

> My intention is to use the  JMX web interface to shutdown JBoss 
> cleanly. Of course not all applications have an additional interface 
> for shutting down, unlike JBoss or Tomcat. Instead of using a PID or 
> similar file the wrapper could use the Tomcat approach and listen for 
> a shutdown command on a well-known port, or implement a JMX interface. 

I am planning to get JMX support added to the Wrapper in the next or 
following
version.  As for the well known port option, this was implemented in 
3.0.4.  See
the WrapperActionServer class for details.  I need to document it a 
little better,
but you can see an example of it in action in the TestWrapper application.

Cheers,
Leif

Re: [Wrapper-user] Newbie (?) Questions

[Georg S. <geo...@ti...>]

Leif,

that is really great, thanks a lot!

My intention is to use the  JMX web interface to shutdown JBoss cleanly. 
Of course not all applications have an additional interface for shutting 
down, unlike JBoss or Tomcat. Instead of using a PID or similar file the 
wrapper could use the Tomcat approach and listen for a shutdown command 
on a well-known port, or implement a JMX interface.

[When we actually start using the wrapper in our production environment 
I am going to talk about the money issue with my boss.]

Regards
Georg

Leif Mortenson wrote:

> Georg,
>    Ok, I got both of this issues implemented / fixed.  They will be in 
> the next release.
> See below for comments.
>
> Georg Schmid wrote:
>
>> Leif,
>>
>> thanks for the detailed explanation. I have understood all the points 
>> you made.
>>
>> I  cannot agree with you on the first point. The practical effect is, 
>> that, if the process runs into an error condition, which does not go 
>> away through restarting, the crashing-and-restarting process will 
>> loop forever (which has to be avoided under all circumstances. It may 
>> take several hours, until the service people react and fix the 
>> situation. During this time the endless loop may do a lot of harm by 
>> opening more and more files and database connections without closing 
>> them, which may exhaust the available file handles as well as the 
>> maximum number of database connections, all in all creating a lot 
>> more damage than simply staying down after 5 retries). Moreover, 
>> according to the documentation, the retry count will be reset, if the 
>> process has been running successfully for more than a specified time. 
>
>
>    This made good sense, so the Wrapper no longer treats restarts 
> triggered by
> calling WrapperManager.restart() or those triggered by a filter, 
> specially.  Any
> restart will cause the failed invocation count to be incremented if 
> the JVM was
> running for less than the configured successful invocation time.
>
>> For the second issue there has to be made a difference between the 
>> reaction of the process controlled by the wrapper and the wrapper 
>> itself. Even if the wrapper restarts a process that has received a 
>> TERM, the wrapper itself can still react to this signal by shutting 
>> down.  But this is not the point.  The wrapper should NOT go down 
>> when receiving a TERM, it should stay. Otherwise it would be 
>> vulnerable itself to a forgotten "nohup" or, taking my situation, 
>> TERM signals with unknown sources.
>> Instead it should be possible to shutdown the wrapper by, for 
>> instance, creating a "well-known" file. Many of the processes in our 
>> manufacturing environment catch all signals they can, because they 
>> must not be interrupted in their activities during certain periods of 
>> time and are shut down in this way.
>>
>>> Processes should always respond to a kill TERM by exiting gracefully.
>>
>>
>>
>> Not always. For instance, if the foreground process of a Bourne shell 
>> gets a Ctrl-C, the shell sends a TERM to all processes it has started 
>> in the background. The background processes should, of course, ignore 
>> this TERM in this situation. (I only know this, because there is a 
>> related JDK1.4 bug). 
>
>
> I added a new wrapper.ignore_signals property which, if set, will 
> cause the
> to ignore TERM and INT signals on UNIX, and CTRL-C and Window CLOSE
> events on Windows.  It is documented, but as is, the scripts which 
> ship with
> the Wrapper will not be able to stop the Wrapper if this property is set.
>
> How are you planning of having your application shut itself down?  I 
> may need
> to do some more work here to maybe create a shell script that kills the
> Wrapper by deleting its pid file rather than sending a TERM signal.  
> Doing
> so would mean that the Wrapper would have to poll for the existence of 
> the file
> to decide when to exit.  Thoughts?
>
> If you find these features and support useful, please consider 
> supporting the
> project.
> http://wrapper.tanukisoftware.org/doc/english/donate.html
>
> Cheers,
> Leif
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user


-- 
--
Georg Schmid
Special Applications Section Manager   mailto:geo...@ti...
Freising Wafer Fab (FFAB) Make IT      phone: +49 8161 804595
Texas Instruments Deutschland GmbH     fax: +49 8161 803350
              

Re: [Wrapper-user] Wrapper configuration problems

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

Max,
Originally, the Wrapper's property file worked almost exactly like the
java.util.Properties class. However there have been a couple features which
have caused it to diverge slightly.

1) The ability to set environment variables. It is possible to define a
property
like the following:
set.JAVA_HOME=../jre
This value can then be used as follows:
wrapper.java.command=%JAVA_HOME%/bin/java
Environment variables in the properties file are expanded as the
properties are
loaded from the file. For this reason, it is necessary to define the
environment
variable at a point in the file before it is used.

2) Include files. It is possible to specify other properties files that
will be recursively
read in at the point that they are declared. Properties defined in the
include files
follow the above rule.

3) I think this is the same as the java Properties class, but any
properties that are
defined more than once will end up with the value declared last.

Once all of the properties are loaded however, they are accessed as a
hash map so
there should be absolutely no further dependency on the order of the
properties in
the file.

Would it be possible for you post exactly what properties are causing you
problems? What you are describing, with the above exceptions, should not be
happening, so I would like to see what you are referring to.

Cheers,
Leif

Max Stolyarov wrote:

> Leif,
>
> I wrote a code to dynamically modify wrapper.conf file in order to on
> the fly change NT service's name, display name, and service
> description parameters. When I analyzed this file, I though that this
> is a simple properties file that you probably read and then apply
> internally. Because of this, I thought that the order in which
> parameters appear in the file does not matter. Apparently I thought
> wrong. In my file, parameters were in different order then in your
> file, and when I tried to install the wrapper and run my application
> as a service, it did not; the NT service did not start. In order to
> trouble shoot the problem, I replaced my file with your wrapper.conf
> file, tried to load and start the service again and it worked. (Number
> of parameters in each file is the same). Therefore, I feel that for
> some reason or not, the order in which parameters appear in your
> wrapper.conf file is very important. Can you please let me know why
> did you handle properties in such a way? Also, if this is not
> something you planned for can you please update file that reads
> configuration properties, to first read it and then apply them, so
> that the order in which they appear in the Config file is not
> important. Thanks in advance.
>
> Max
>

Re: [Wrapper-user] java proc starts then restarts

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

Marshall,
This is being caused because the WrapperManager class is not being loaded
and initialized in the JVM. I added a comment to template wrapper.conf
for the
next release to make this more clear. But the main class in most cases
should
not be your application's main class. The Wrapper provides a couple of
helper
classes to initialize the WrapperManager and then launch your application.

Please read the documentation. Especially the section of Integration:
http://wrapper.tanukisoftware.org/doc/english/integrate.html
You will most likely want to use method #1.

Post back if you still have problems getting things working after
looking over
those docs.

Cheers,
Leif

P.S. Supporting the project with a donation helps us to continue
providing you
and others with a high quality product. The thanks you in advance.

[Wrapper-user] java proc starts then restarts

[Moritomo, M. <Mar...@pe...>]

Wrapper Users,

            I was able to get my java proc to start using wrapper.  However,
it restarts due to the following error: (see bottom)

C:\eGateway\server>TestWrapper.bat

STATUS | wrapper  | 2003/09/02 23:13:18 | --> Wrapper Started as Console

DEBUG  | wrapperp | 2003/09/02 23:13:18 | server listening on port 32001.

STATUS | wrapper  | 2003/09/02 23:13:19 | Launching a JVM...

DEBUG  | wrapper  | 2003/09/02 23:13:19 | command: "..\_jvm\bin\java"
-Dwsf.prop

erties=/eGateway/common/WSFProperties.properties
-DLogging.properties=/eGateway/

common/EgatewayServerLoggingProperties.properties -Xms3m -Xmx128m
-Djava.library

.path="../lib" -classpath
"../lib/wrapper.jar;../lib/wrappertest.jar;../lib/brok

er.jar;../lib/sslj.jar;../lib/certj.jar;../lib/jsafe.jar;../lib/jms.jar;../l
ib/c

lient.jar;../lib/bootstrapper.jar;../lib/server.jar;../lib/domain.jar;../lib
/cas

l.jar;../lib/services.jar;../lib/jsse.jar;../lib/jnet.jar;../lib/jcert.jar;.
./li

b/classes12.zip;../lib/mysql-connector-java-2.0.14-bin.jar;../lib/jdom.jar;.
./li

b/xerces.jar;../lib/jdmktk.jar;../lib/jdmkrt.jar;../lib/log4j.jar"
-Dwrapper.key

="95djfkaE0vYmIMLt" -Dwrapper.port=32001 -Dwrapper.debug="TRUE"
-Dwrapper.disabl

e_shutdown_hook="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1
com.ncs.egat

eway.server.EGatewayServer

DEBUG  | wrapper  | 2003/09/02 23:13:19 | Java Virtual Machine started
(PID=2432

)

INFO   | jvm 1    | 2003/09/02 23:13:20 | 821  [main] INFO
EGatewayServerConsol

eNotification  - Finished starting http services...

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[cons(properties)]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=ParentJXMSecureConnection]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=TrustStorePassword]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=Password]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=KeyStorePassword]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=ParentJMXServerPort]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=JMXSecureHtmlPort]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=ParentJMXAddress]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=JMXCustomParserClassName]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=Username]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=JMXServerPort]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=RegisterDomain]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=ParentJMXPassword]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=KeyStore]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=KeyStoreType]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=protocol]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=DatabaseURL]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=JMXSecureConnection]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=ParentJMXUserName]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=UseJMXPullMode]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=JMXEnableAuthorization]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=DriverName]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=SystemName]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=JMXClientListenPort]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=RegisterWithParent]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=JMXHtmlPort]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=TrustStore]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[getMBeanInfo]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[cons(properties)]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A1.File]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A1.layout.Conv

ersionPattern]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.configDebug]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A2.File]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A2.layout]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A2]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A1]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A1.layout]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A2.layout.Conv

ersionPattern]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.rootCategory]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[getMBeanInfo]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[cons(properties)]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A1.File]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A1.layout.Conv

ersionPattern]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.configDebug]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A2.File]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A2.layout]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A2]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.appender.A1]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A1.layout]x

INFO   | jvm 1    | 2003/09/02 23:13:20 |
x[strKey=log4j.appender.A2.layout.Conv

ersionPattern]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[strKey=log4j.rootCategory]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | x[getMBeanInfo]x

INFO   | jvm 1    | 2003/09/02 23:13:20 | 1112 [main] INFO
EGatewayServerConsol

eNotification  - Initializing logging...

INFO   | jvm 1    | 2003/09/02 23:13:20 | 1112 [main] INFO
EGatewayServerConsol

eNotification  - Starting eGateway Server Thread...

INFO   | jvm 1    | 2003/09/02 23:13:20 | 1112 [main] INFO
EGatewayServerConsol

eNotification  - eGateway Server Thread Started.

INFO   | jvm 1    | 2003/09/02 23:13:20 | 1112 [Thread-1] INFO
EGatewayServerCo

nsoleNotification  - eGateway initialization complete.

ERROR  | wrapper  | 2003/09/02 23:14:00 | Startup failed: Timed out waiting
for

signal from JVM.

ERROR  | wrapper  | 2003/09/02 23:14:00 | Java Virtual Machine did not exit
on r

equest, terminated

DEBUG  | wrapper  | 2003/09/02 23:14:00 | JVM was only running for 41
seconds le

ading to a failed restart count of 1.

 

Can I turn off the "Timed out waiting for signal from JVM" test???  This
java proc is just suppose to listen for incoming traffic - then process when
transaction when need be.

 

Marshall Moritomo
UNIX Systems Administrator

Pearson Digital Learning

827 West Grove Avenue
Mesa, Arizona  85210-4931
Phone: 480.610.7543

Fax: 480.827.7224
http://www.pearsondigital.com/ <http://www.pearsondigital.com/> 

 


**************************************************************************** 
This email may contain confidential material. 
If you were not an intended recipient, 
Please notify the sender and delete all copies. 
We may monitor email to and from our network. 
****************************************************************************

Re: [Wrapper-user] Newbie (?) Questions

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

Georg,
    Ok, I got both of this issues implemented / fixed.  They will be in 
the next release.
See below for comments.

Georg Schmid wrote:

> Leif,
>
> thanks for the detailed explanation. I have understood all the points 
> you made.
>
> I  cannot agree with you on the first point. The practical effect is, 
> that, if the process runs into an error condition, which does not go 
> away through restarting, the crashing-and-restarting process will loop 
> forever (which has to be avoided under all circumstances. It may take 
> several hours, until the service people react and fix the situation. 
> During this time the endless loop may do a lot of harm by opening more 
> and more files and database connections without closing them, which 
> may exhaust the available file handles as well as the maximum number 
> of database connections, all in all creating a lot more damage than 
> simply staying down after 5 retries). Moreover, according to the 
> documentation, the retry count will be reset, if the process has been 
> running successfully for more than a specified time. 

    This made good sense, so the Wrapper no longer treats restarts 
triggered by
calling WrapperManager.restart() or those triggered by a filter, 
specially.  Any
restart will cause the failed invocation count to be incremented if the 
JVM was
running for less than the configured successful invocation time.

> For the second issue there has to be made a difference between the 
> reaction of the process controlled by the wrapper and the wrapper 
> itself. Even if the wrapper restarts a process that has received a 
> TERM, the wrapper itself can still react to this signal by shutting 
> down.  But this is not the point.  The wrapper should NOT go down when 
> receiving a TERM, it should stay. Otherwise it would be vulnerable 
> itself to a forgotten "nohup" or, taking my situation, TERM signals 
> with unknown sources.
> Instead it should be possible to shutdown the wrapper by, for 
> instance, creating a "well-known" file. Many of the processes in our 
> manufacturing environment catch all signals they can, because they 
> must not be interrupted in their activities during certain periods of 
> time and are shut down in this way.
>
>> Processes should always respond to a kill TERM by exiting gracefully.
>
>
> Not always. For instance, if the foreground process of a Bourne shell 
> gets a Ctrl-C, the shell sends a TERM to all processes it has started 
> in the background. The background processes should, of course, ignore 
> this TERM in this situation. (I only know this, because there is a 
> related JDK1.4 bug). 

I added a new wrapper.ignore_signals property which, if set, will cause the
to ignore TERM and INT signals on UNIX, and CTRL-C and Window CLOSE
events on Windows.  It is documented, but as is, the scripts which ship with
the Wrapper will not be able to stop the Wrapper if this property is set.

How are you planning of having your application shut itself down?  I may 
need
to do some more work here to maybe create a shell script that kills the
Wrapper by deleting its pid file rather than sending a TERM signal.  Doing
so would mean that the Wrapper would have to poll for the existence of 
the file
to decide when to exit.  Thoughts?

If you find these features and support useful, please consider 
supporting the
project.
http://wrapper.tanukisoftware.org/doc/english/donate.html

Cheers,
Leif

[Wrapper-user] Wrapper configuration problems

[Max S. <MSt...@li...>]

Leif,

 

   I wrote a code to dynamically modify wrapper.conf file in order to on the
fly change NT service's name, display name, and service description
parameters. When I analyzed this file, I though that this is a simple
properties file that you probably read and then apply internally. Because of
this, I thought that the order in which parameters appear in the file does
not matter. Apparently I thought wrong. In my file, parameters were in
different order then in your file, and when I tried to install the wrapper
and run my application as a service, it did not; the NT service did not
start. In order to trouble shoot the problem, I replaced my file with your
wrapper.conf file, tried to load and start the service again and it worked.
(Number of parameters in each file is the same). Therefore, I feel that for
some reason or not, the order in which parameters appear in your
wrapper.conf file is very important. Can you please let me know why did you
handle properties in such a way? Also, if this is not something you planned
for can you please update file that reads configuration properties, to first
read it and then apply them, so that the order in which they appear in the
Config file is not important. Thanks in advance.

 

 

Max

Re: [Wrapper-user] console not displayed when interact with desktop is on

[<da...@ix...>]

In article <3F4...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>Anyway, it is at http://wrapper.tanukisoftware.org/tools/TAIL2.EXE
>The only parameter is the file you want to tail.

Since Wrapper can rotate the log file, will this interfere with that in any
way?

I tend to install MSYS and use the tail that comes with that system.

mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

RE: [Wrapper-user] console not displayed when interact with desktop is on

[Andy B. <and...@rc...>]

Ok, thanks for this.
Andy

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: Thursday, August 28, 2003 4:50 PM
To: wra...@li...
Subject: Re: [Wrapper-user] console not displayed when interact with
desktop is on


Andy,
(Excuse me but AHHHHHH!!!)  Sorry, I worked hard to get rid of the
Console. :-)
Most users only wish to display a Swing GUI in interactive mode and they are
opposed to an "ugly" console being left around.   The behavior of the
console
is a little different with each of the various JVMs.   I'll look into
adding a way to
show the console when run as a service.  It shouldn't be too difficult.

One option in the mean time is to use a tail program to view the log
output.
I placed a great little tool that I always use up on the web server.  I
found it a
few years ago.  I like to give credit where credit is due, but I
honestly can't
remember where I found it :-/
Anyway, it is at http://wrapper.tanukisoftware.org/tools/TAIL2.EXE
The only parameter is the file you want to tail.

Cheers,
Leif

Andy Birchall wrote:

>Hi,
>I am running my app as a service in Windows 2000 with JDK 1.4.2.
>I have wrapper.ntservice.interactive=true in the wrapper.conf file but
>when I start the service a console window (dos box) does not appear.
>Ouput only goes to the wrapper.log file.
>I have tried setting wrapper.ntservice.hide-console=false but this makes
>no difference.
>Regards
>Andy Birchall
>Archive-IT
>
>
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

_____________________________________________________________________
This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further
information visit http://www.mci.com

Re: [Wrapper-user] console not displayed when interact with desktop is on

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

Andy,
(Excuse me but AHHHHHH!!!)  Sorry, I worked hard to get rid of the 
Console. :-)
Most users only wish to display a Swing GUI in interactive mode and they are
opposed to an "ugly" console being left around.   The behavior of the 
console
is a little different with each of the various JVMs.   I'll look into 
adding a way to
show the console when run as a service.  It shouldn't be too difficult.

One option in the mean time is to use a tail program to view the log 
output. 
I placed a great little tool that I always use up on the web server.  I 
found it a
few years ago.  I like to give credit where credit is due, but I 
honestly can't
remember where I found it :-/
Anyway, it is at http://wrapper.tanukisoftware.org/tools/TAIL2.EXE
The only parameter is the file you want to tail.

Cheers,
Leif

Andy Birchall wrote:

>Hi,
>I am running my app as a service in Windows 2000 with JDK 1.4.2.
>I have wrapper.ntservice.interactive=true in the wrapper.conf file but
>when I start the service a console window (dos box) does not appear.
>Ouput only goes to the wrapper.log file.
>I have tried setting wrapper.ntservice.hide-console=false but this makes
>no difference.
>Regards
>Andy Birchall
>Archive-IT
>
>  
>

[Wrapper-user] console not displayed when interact with desktop is on

[Andy B. <and...@rc...>]

Hi,
I am running my app as a service in Windows 2000 with JDK 1.4.2.
I have wrapper.ntservice.interactive=true in the wrapper.conf file but
when I start the service a console window (dos box) does not appear.
Ouput only goes to the wrapper.log file.
I have tried setting wrapper.ntservice.hide-console=false but this makes
no difference.
Regards
Andy Birchall
Archive-IT