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

[Wrapper-user] Two wrapper.log files ...

[Yasir K. <yas...@as...>]

Hi,

In wrapper.conf file I have given the specific path of wrapper.log file i.e. my application's log directory. I successfully installed the service using method-1. Now when I start the service, two wrapper.log files are created, one in my application's log directory (its OK) other is created in the same directory where wrapper.exe is placed (why one is created here?). First wrapper.log contains some wrapper messages and the application output that is printed as System.out or System.in (its OK) but the other wrapper.log contains the following message.   

WARN   | wrapper  | 2003/10/21 10:52:44 | Unable to expand environment variable, CLASSPATH as it would be longer than the 16384 byte buffer size.

Why this second wrapper.log file is created and what is it indicating ..?

Best Regards,
Yasir Khan

[Wrapper-user] Registering application's shut down hook ...?

[Yasir K. <yas...@as...>]

Hi,

"If the application has registered its own shutdown hook, it will be invoked, giving the application a chance to shutdown cleanly. If on the other hand, a shutdown hook is not registered, then the application will suddenly exit." 

Above text is taken from the integration method-1 introduction. I just want to ask that what is meant by registering shut down hook and how can a JAVA application register its own shutdown hook, so that it could be invoked using integration method-1?. Thanx.  

Best Regards,
Yasir Khan

[Wrapper-user] Re: RE: Re: Win2000 Service problem

[EXT-Smith, E. M <eri...@bo...>]

Leif,

-----Original Message-----
> There was a typo that was preventing the latest=20
> environment variable values from being loaded from=20
> the registry.  *envKeys as being tested against NULL=20
> to see if the calloc was successful.  But it should=20
> have just been envKeys (without the '*')  My tests=20
> show that this change to your patch is correct, but=20
> can you confirm this just in case I am missing something?

You're right for the *envKeys on line 1260 "if ( NULL !=3D *envKeys ) {" =
 I wanted to test for the first level array allocation, not the internal =
buffer allocation at that point.


> What were the problem(s) that you had been seeing=20
> that led you to look for, and then fix this?  As I=20
> said, I had never seen any problems arise due to=20
> the misuse of the putenv function and would like to=20
> understand the symptoms so I can answer questions=20
> posed by other users.  I also want to describe the=20
> problem being solved in the release notes.

Here's the basic sequence I followed.  It's a bit long winded, but =
fairly complete.  Item 8 details the debug info I saw that lead me to =
the problem:

1) I put valid environment variables into the config file expecting them =
to be resolved correctly.
2) I then executed the service as a console app.  Everything worked.
3) I installed the app as a service.  Still everything worked.
4) I tried running the app as a service.  The service reported starting =
and after about 10 seconds, stopping.  First sign of trouble.
5) I looked at the log and noticed a Number Format error on one of the =
environment variables.  When I looked at the variable declarations, I =
noticed the variable was declared for the "current user" instead of =
system.  Moved the variable to System, and rebooted.
6) I tried running the app as a service.  The service reported starting =
and after about 10 seconds, stopping.  Trouble still exists.
7) Tried alternately executing service as a console app and service and =
examining logs.  Continuously adding more debug statements as we =
narrowed down where the problem occurred.
8) Finally added debug statements to the method that performs the =
putenv/getenv.  After running with this, I noticed the following:
	a) The environment variable causing problems was the first environment =
variable loaded from the registry.
	b) In the first loop, the value was read in, resolved properly, =
displayed in my debug statements, and the putenv was called =
successfully.
	c) If I checked the environment immediately following the putenv, =
everything was ok.
	d) If I checked the environment after all putenv() calls, then all =
environment values except the first one (the one I needed) were =
accessible using getenv.  The first one was not there.
9) Researched the putenv()/getenv() methods and found the quote I sent =
in my last message.
10) Made the modifications I sent to you.
11) Ran numerous tests at different debugging levels to determine =
whether the patch worked.
12) Uninstalled all services and rebooted the machine (to start from a =
clean slate).
13) Reinstalled all services and launched them as services from the =
command line (all started successfully).
14) Rebooted the machine to make sure all services started.  They all =
started successfully.


On a stylistic note...

<        if (*envKeys !=3D NULL) {
            dwIndex =3D 0;

I noticed that you write your if statements in a variable -- value =
sequence. =20
As a defensive coding practice I write mine in a value -- variable =
sequence for the following reason:
	A compiler will report
		if ( NULL =3D envKeys ) { ... }		// should be if ( NULL =3D=3D envKeys =
) { ... }
			as an error.


Sincerely,

Eric M. Smith
InfoStructure Systems
Boeing Chairman's Innovation Initiative

[Wrapper-user] running shutdown class when stopping linux daemon

[Ori A. <ori...@ap...>]

Hi,
I have a shutdown class that needs to be called when stopping the
daemon, and the way the sh script looks, it just kills the java process
without calling it. Is this true? I don't see the shutdown class being
activated in the logs.
(As NT service on windows it works fine)
Should I just enter a call to another shutdown sh there? That seems like
ignoring the conf file and going back to scripts, which feels wrong.
 
Ori
 

[Wrapper-user] On non std options java.intimemory, maxmemory

[Prashant R. <pra...@pr...>]

Just printed out my "command" in wrapper.log and saw it use non-std options
to map init memory(-Xms), max memory(-Xmx) to sun's jdk.

Dont know if they are infact different on different JVMs.,but just
wondering...

Do options wrapper.java.initmemory=16 , wrapper.java.maxmemory=64 work on
other JVM releases? If wrapper has mapped these options, then on what all
jvm releases.

Thanks

Prashant

[Wrapper-user] =?ISO-8859-1?B?UmU6IFByb2JsZW0gd2l0aCBpbmNsdWRlIGluIGxpbnV4?=

[Daniel C. <dan...@gi...>]

Hi

Thank you for your help.

I solved the problem. When a had the problem I copied the wrapper_server.co=
nf file from a windows machine to the linux machine with ftp. When I instea=
d created the file as a new file on linux with emacs and with ssh pasted th=
e contents into the file everything worked.

The text contents was the same in both tests but comparing the files showed=
 that the binary contents was not. My guess is that the file got som wrong =
character encoding and then wrapper either didn't see the #include line at =
all becuase # was encoded differently or it saw the line but couldn't find =
the file because its filename had som different encoding.

Just so you known.=20

/Daniel

Leif wrote:

Daniel,
     I just retested this and it is working correctly on my machine.  =20
 There is currently no
 easy way to debug this because the include system is designed to simply=20
 ignore files that
 can not be found.
=20
     It sounds like you have already tried most things.  The next thing=20
 that I would suggest
 will involve building from source?  It is easy.
=20
     Download the src tar file.  (You do not need the big one with the=20
 document source.)
 Edit the src/c/Makefile.linux file and append a debug flag to the=20
 COMPILE options
 on the first line.  It will look like this:
=20
 COMPILE =3D gcc -O3 -Wall --pedantic -D_DEBUG
=20
 Now from the root of the source, simply run ./build.sh  This will=20
 recompile everything.
 Copy the new wrapper binary to your project and try launching the=20
 wrapper again.
 You will get a lot of debug output.  The beginning goes through the=20
 process of reading
 in the conf file and any includes.   It is not very user friendly, so=20
 post the output back to
 the list and I'll see if I can see your problem.
=20
 Please post your wrapper.conf and wrapper_server.conf files as well.
=20
 Cheers,
 Leif
=20
 Daniel Carlsson wrote:
=20
 >Hi
 >
 >I am using #include in a file called "wrapper_server.conf" to include a f=
ile named
"wrapper.conf", both placed in the same directory as the executable. Everyt=
hing works
perfectly on windows but does not work att all on linux (Redhat 8.0, sun ja=
va 1.4.1_02-b06).
I have tried wrapper 3.0.4 and 3.0.5.
 >
 >I have tried moveing the include line around and rewritting it as:
 >#include wrapper.conf
 ># include wrapper.conf
 >#include ./wrapper.conf
 >#include /opt/fox/fox_f03/wrapper/wrapper.conf
 >
 >Nothing works and I can't understand why. Has somebody successfully run i=
ncludes in linux?
Does somebody know why it doesn't work?
 >
 >Thanks
 >
 >Daniel Carlsson=20
 >Gimlisoft AB
 >Email: daniel.carlsson@gi...
 >Tel: 0709-744570, 031-189024
 > =20
 >
=20



Med v=E4nliga h=E4lsningar

Daniel Carlsson=20
Gimlisoft AB
Email: dan...@gi...
Tel: 0709-744570, 031-189024

Re: [Wrapper-user] Error occured when JNI code is executed

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

Yasir,

> I downloaded Java Service Wrapper today and now trying to run my 
> application using method 1 on windows 2000. My application interact 
> with some of NT native functionality using JNI. Now problem is that 
> when I start my application on clicking on the MyApp.bat file my 
> application starts executing and execution fails when it tries to 
> load a DLL with following exception (please note that I have 
> not installed the service yet for my application)
>  
> jvm 1    | System tray DLL error
> jvm 1    | System tray ICON error
> jvm 1    | java.lang.UnsatisfiedLinkError: nativeMoveToFront
> jvm 1    |      at 
> com.gc.systray.SystemTrayIconManager.nativeMoveToFront(Native Method)
> jvm 1    |      at 
> com.gc.systray.SystemTrayIconManager.<init>(SystemTrayIconManager.java:69)
> jvm 1    |      at 
> com.gc.systray.DefaultSystemTray.<init>(DefaultSystemTray.java:48)
> jvm 1    |      at ASC_SplashScreen$2.run(ASC_SplashScreen.java:98)
> jvm 1    |      at java.lang.Thread.run(Unknown Source)
>  
> Any ideas why JNI is not working properly?

When your application was running without theWrapper, it was using a 
native library.
Java locates its native libraries using a special library path.   This 
was either specified
on the command line or as an environment variable.  When you locate it, 
you will
need to add an additional line to the wrapper.conf file to tell the 
wrapper where to
locate the additional native libraries.  It will look something like this:
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=c:/AdditionalJNILibraries/lib  

> Also I want to know that as my application is running under a 
> wrapper, performance of my application will be affected, what u people 
> say about performance issue?

I have never noticed any performance differences when using the 
Wrapper.  It is
designed to be very light weight.  The exception is when you dump very large
quantities of output to the console.   Then there is a slight 
performance decrease
but it is small and can be worked around in a number of ways using java 
site logging
tools.

Cheers,
Leif

Re: [Wrapper-user] Error occured when JNI code is executed

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

HMM I replied to this yesterday but it never showed up on the
list!?!

Here is a repost.
-Leif

---
Yasir,

> I downloaded Java Service Wrapper today and now trying to run my 
> application using method 1 on windows 2000. My application interact 
> with some of NT native functionality using JNI. Now problem is that 
> when I start my application on clicking on the MyApp.bat file my 
> application starts executing and execution fails when it tries to load 
> a DLL with following exception (please note that I have not installed 
> the service yet for my application)
>  
> jvm 1    | System tray DLL error
> jvm 1    | System tray ICON error
> jvm 1    | java.lang.UnsatisfiedLinkError: nativeMoveToFront
> jvm 1    |      at 
> com.gc.systray.SystemTrayIconManager.nativeMoveToFront(Native Method)
> jvm 1    |      at 
> com.gc.systray.SystemTrayIconManager.<init>(SystemTrayIconManager.java:69) 
>
> jvm 1    |      at 
> com.gc.systray.DefaultSystemTray.<init>(DefaultSystemTray.java:48)
> jvm 1    |      at ASC_SplashScreen$2.run(ASC_SplashScreen.java:98)
> jvm 1    |      at java.lang.Thread.run(Unknown Source)
>  
> Any ideas why JNI is not working properly?


When your application was running without the Wrapper, it was
using a native library.  Java locates its native libraries using a
special library path.   This was either specified on the command
line or as an environment variable.  When you locate it, you will
need to add an additional line to the wrapper.conf file to tell
the wrapper where to locate the additional native libraries.  It
will look something like this:

wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=c:/AdditionalJNILibraries/lib 

> Also I want to know that as my application is running under a wrapper, 
> performance of my application will be affected, what u people say 
> about performance issue?

I have never noticed any performance differences when using the
Wrapper.  It is designed to be very light weight.  The exception
is when you dump very large quantities of output to the console.
Then there is a slight performance decrease but it is small and
can be worked around in a number of ways using java site logging
tools.

Cheers,
Leif

Re: [Wrapper-user] RE: Re: Win2000 Service problem

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

Eric,
    Thanks for the patch.  I got it committed.   There was a typo that 
was preventing
the latest environment variable values from being loaded from the 
registry.  *envKeys
was being tested against NULL to see if the calloc was successful.  But 
it should have
just been envKeys (without the '*')  My tests show that this change to 
your patch is
correct, but can you confirm this just in case I am missing something?

    If you rerun the test, you should now see the environment variables 
being loaded in
from the registry.  They will be in their raw unexpanded format.  That 
is what the
following loop is there for.  It goes through and expands variables 
iteratively until it
reaches a point where they are all expanded.   This process will only 
happen once
when the Wrapper is first started, even if the JVM is restarted one or 
more times.

----
            envKeysCount = dwIndex;
        }
<        if (*envKeys != NULL) {
            dwIndex = 0;
----
            envKeysCount = dwIndex;
        }
 >        if (envKeys != NULL) {
            dwIndex = 0;
----

    The point of that whole block of code is to load the environment 
variables from the
registry so that are made available to the wrapper when run as a 
service.   If this is not
done then the user would be required to reboot the machine in order to 
make system
level environment variable changes available to the service.  That was a 
major PITA
even if it is a norm for Windows(tm) users.  So I added that little work 
around.  :-)

    Things have always worked fine for me, so I am glad you spotted 
this.  It would have
been quite difficult for me to track down.

>Last evening I was trying to get our 7 services running under WinXP and discovered something that may be the underlying cause of a large number of problems on the Windows platforms.
>  
>
I am not sure that the original problem you were replying to is caused 
by this however.
I am waiting for a log file as it looks like a standard environment 
problem.  I'll be able
to tell for sure when I get the log.

What were the problem(s) that you had been seeing that led you to look 
for, and
then fix this?  As I said, I had never seen any problems arise due to 
the misuse of
the putenv function and would like to understand the symptoms so I can 
answer
questions posed by other users.  I also want to describe the problem 
being solved
in the release notes.

Thanks again for taking the time to make the patch.
Cheers,
Leif

Re: [Wrapper-user] Win 2000 Service problem

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

Stefan,
    Thank you.  That log file shows that the service was installed 
correctly.  But the
problem is with the startup of the service.

    I am looking for the log output from when the service is started, 
rather than when
it is installed.   My fault because I didn't explain this.  But if the 
Wrapper is unable
to locate its wrapper.conf.  Or it is unable to write to the specified 
log file then it
will fall back to writing to a file called wrapper.log that is located 
in the same directory
as the Wrapper.exe.   That may be where the log output that I am looking 
for is
located.   Under some failure modes, the file may also exist in the 
Windows\system32
directory, also named wrapper.log.   Could you please check those two 
locations?

    The problem may be that you have defined the following log file 
location.
wrapper.logfile=%WKDIR%logs/HRScannerService.log
    If the WKDIR environment variable can not be resolved for any reason 
then this
file will not be valid and the wrapper will fall back to writing to a 
wrapper.log file as
described above.

    Cheers,
    Leif


Stefan Maric wrote:

>OK
>
>Have killed off previous log files
>
>Attached log file shows o/p from running InstallApp-NT.bat
>
>Win2K Services
>myService - set Log On As local admin
>myService start
>
>No additional entries in log file ?????
>
>
>*******************Relevant contents of InstallApp-NT.bat*******************
>rem
>rem Run the application.
>rem At runtime, the current directory will be that of Wrapper.exe
>rem
>:startup
>"C:\wrapper_win32_3.0.5\bin\Wrapper.exe" -i
>h:\com\eaac\HRWrapper\wrapper.conf
>if not errorlevel 1 goto end
>pause
>*******************Relevant contents of InstallApp-NT.bat*******************
>
>
>
>Regards
>Stefan Maric
>European Aviation Air Charter
>01202 581111 x184
>  
>

RE: [Wrapper-user] Occasional wrapper restart under light load

[Bill L. <bli...@to...>]

Hi Leif-

As always, thanks for your help with this issue.

See my comments below.

-Bill


> Bill,
>     That is a big log (20MB)  I asked for it though. :-)   I found a=20
> single restart in the logs.
> You originally started the application at 2003/10/08 17:30:04=20
> and it was=20
> running fine until
> 2003/10/14 10:43:03 when it was restarted due to a ping timeout.  The=20
> service was then
> stopped manually at 2003/10/15 07:49:06.  You are correct.  That is a=20
> long time to
> reproduce the problem.


I have actually been monitoring the computer since approximately
2003/10/02, so it is even worse than that. Sometimes it can happen
within a day or two of starting the application, and sometimes it is
close to a month.


>     Scanning through the logs, it looks like the highest frequency of=20
> garbage collection
> happened right before the JVM was restarted.  Each of the=20
> individual GC=20
> sweeps was
> very short, but there were a lot of them.


You may be right but it may be impossible to tell from the logs. We are
using a flag that instructs the JVM to trace the GCs and to send them to
a file. Unfortunately, not all of the GC messages are sent to the file.
Some of them are sent to stdout (or it could be stderr, I don't know).
These are the messages that end up in your logs. Doubly (or triply)
unfortunate, the JVM overwrites the GC log on restart, so the GC
behavior captured in the file before the app stopped is now gone. (Hmmm,
maybe I should turn off the GC messages to the file and turn on the flag
to send them to stdout, but that may flood the wrapper logs.)


>     Looking at the log, the last successful ping was at 2003/10/14=20
> 10:39:57, or 186
> seconds before Wrapper timed out waiting for a ping.  The=20
> previous pings=20
> had all been
> completing like clockwork once every 6 seconds.
>=20
>     One thing I noticed is that there is no Java side output=20
> in the log=20
> except for immediately
> after the JVM is launched.   Is your application redirecting this=20
> output?  And if so would it
> be possible for you to send me that as well?   It might give me some=20
> additional clues.
> Esp whether or not the JVM is receiving the final ping request.

Yes, our logs redirect stdout and stderr. I sent you our app logs a
little while after I sent you the Wrapper logs. Let me know if you did
not get them.


>     From the log so far, I do not have a lot of ideas.  Everything is=20
> running fine and then the
> JVM stops receiving or responding to pings.   I have a Wrapper=20
> controlled app running on
> a Win2k at home that has been up for about 7 weeks, so I=20
> don't think it=20
> is a time issue.
>=20
>     I'll try and think of other ideas.
>=20
> >>    The problem is that before the JVM is restarted, there are no=20
> >>messages from
> >>the JVM about having received any packets.
> >>   =20
> >>
> >
> >
> >I will go back through the logs and see when the wrapper behavior
> >changed and will see if it correlates with any events on the=20
> application
> >side.
> >
> Great, let me know what you find out.
>=20
> >>collection by adding the -Xincgc.   I was not sure what the
> >>-XX:+UseConcMarkSweepGC option does?
> >>   =20
> >>
> >
> >
> >A couple of months ago, we had some major memory/garbage collection
> >issues. After investigation we have found that for our application:
> >
> >1. When using the default garbage collector, if a major collection is
> >performed while some of the JVM is sitting in the paging file, the GC
> >times can increase up to 2 orders of magnitude. We were=20
> getting some 80
> >- 90 second garbage collections! Doubling the RAM solved=20
> this problem.
> >
> >2. We made further improvements in our GC times by using a=20
> GC strategy
> >that is new to 1.4.2, the Concurrent Low Pause collector.=20
> There is lots
> >of information out there about the new GC strategies. One of=20
> the better
> >ones is here: http://java.sun.com/docs/hotspot/gc1.4.2/.=20
> From that web
> >page, it says to: "Use the concurrent low pause collector if your
> >application would benefit from shorter garbage collector=20
> pauses and can
> >afford to share processor resources with the garbage=20
> collector when the
> >application is running." I could be wrong, but I am pretty sure that
> >time in GC is not the issue here.
> >
>     Thanks always more things to study up on....  Thanks for the link.
>=20
> >=20
> >
> >>Also try extending your wrapper.ping.timeout to around 300, 5=20
> >>minutes. =20
> >>If the
> >>problem is GC related, that will hopefully be long enough=20
> to make the=20
> >>problem
> >>go away.   If the problem is GC related, then your=20
> >>application would be
> >>unresponsive to its clients and not just the Wrapper during=20
> this time=20
> >>however,
> >>have you seen such problems?
> >>   =20
> >>
> >
> >
> >I would rather not do that right now. It feels to me like=20
> there is some
> >problem between the wrapper and the application. The=20
> application is not
> >working hard and I don't think it is experiencing major GC pauses.
> >Because it happens so infrequently I would like to do that as a last
> >resort because I won't be comfortable that the issue is fixed for a
> >while.
> >
> Ok, I'll try to think of some other causes.  That is the only=20
> thing in=20
> the logs right now so it
> is what first comes to mind...
>=20
> >>    I can't think of anything off hand that I have fixed=20
> >>since version=20
> >>3.0.2 that would
> >>affect this, but there have been lots of improvements to=20
> the wrapper.=20
> >>You may want
> >>to consider upgrading to version 3.0.5
> >>   =20
> >>
> >
> >
> >We can upgrade on a future version, however the application=20
> is part of a
> >medical device that has tight FDA constraints. We could change the
> >version, but it would be a lot of work. There would be=20
> documentation to
> >change, and even worse, we would have to rerun many tests.=20
> If we knew it
> >would fix the problem, then we would go ahead and do it. Otherwise, I
> >don't want to change.
> >
> Ok, go ahead and stick with 3.0.2 for now.  I don't think=20
> there were any=20
> changes
> that would affect this anyway.
>=20
> You can play with the ping timeout in your version.   But if=20
> you use the=20
> latest version, you
> can also change the actual ping interval.  May be useful.
>=20
> Cheers,
> Leif

I am reproducing a question I had in one of my messages when I sent the
logs directly to you. Perhaps others would be interested also:

One idea I am kicking around is to turn off the JVM pinging from the
Wrapper. Before we used the Wrapper, the application ran continually and
without problem for up to 6 weeks. And that was on a Window 2K box!
There have been changes since then but after we solved the memory/GC
issues, it still appears very stable, with the exception of this
problem. If I do go ahead and turn off the Wrapper's JVM pinging, do you
foresee any possible problems? I am concerned that what is happening
degrades the communication between the Wrapper and my application. After
launching the application, what is the Wrapper actively doing if pinging
is disabled?

Re: [Wrapper-user] Problem with include in linux

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

Daniel,
    I just retested this and it is working correctly on my machine.   
There is currently no
easy way to debug this because the include system is designed to simply 
ignore files that
can not be found.

    It sounds like you have already tried most things.  The next thing 
that I would suggest
will involve building from source?  It is easy.

    Download the src tar file.  (You do not need the big one with the 
document source.)
Edit the src/c/Makefile.linux file and append a debug flag to the 
COMPILE options
on the first line.  It will look like this:

COMPILE = gcc -O3 -Wall --pedantic -D_DEBUG

Now from the root of the source, simply run ./build.sh  This will 
recompile everything.
Copy the new wrapper binary to your project and try launching the 
wrapper again.
You will get a lot of debug output.  The beginning goes through the 
process of reading
in the conf file and any includes.   It is not very user friendly, so 
post the output back to
the list and I'll see if I can see your problem.

Please post your wrapper.conf and wrapper_server.conf files as well.

Cheers,
Leif

Daniel Carlsson wrote:

>Hi
>
>I am using #include in a file called "wrapper_server.conf" to include a file named "wrapper.conf", both placed in the same directory as the executable. Everything works perfectly on windows but does not work att all on linux (Redhat 8.0, sun java 1.4.1_02-b06). I have tried wrapper 3.0.4 and 3.0.5.
>
>I have tried moveing the include line around and rewritting it as:
>#include wrapper.conf
># include wrapper.conf
>#include ./wrapper.conf
>#include /opt/fox/fox_f03/wrapper/wrapper.conf
>
>Nothing works and I can't understand why. Has somebody successfully run includes in linux? Does somebody know why it doesn't work?
>
>Thanks
>
>Daniel Carlsson 
>Gimlisoft AB
>Email: dan...@gi...
>Tel: 0709-744570, 031-189024
>  
>

Re: [Wrapper-user] Occasional wrapper restart under light load

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

Bill,
    That is a big log (20MB)  I asked for it though. :-)   I found a 
single restart in the logs.
You originally started the application at 2003/10/08 17:30:04 and it was 
running fine until
2003/10/14 10:43:03 when it was restarted due to a ping timeout.  The 
service was then
stopped manually at 2003/10/15 07:49:06.  You are correct.  That is a 
long time to
reproduce the problem.

    Scanning through the logs, it looks like the highest frequency of 
garbage collection
happened right before the JVM was restarted.  Each of the individual GC 
sweeps was
very short, but there were a lot of them.

    Looking at the log, the last successful ping was at 2003/10/14 
10:39:57, or 186
seconds before Wrapper timed out waiting for a ping.  The previous pings 
had all been
completing like clockwork once every 6 seconds.

    One thing I noticed is that there is no Java side output in the log 
except for immediately
after the JVM is launched.   Is your application redirecting this 
output?  And if so would it
be possible for you to send me that as well?   It might give me some 
additional clues.
Esp whether or not the JVM is receiving the final ping request.

    From the log so far, I do not have a lot of ideas.  Everything is 
running fine and then the
JVM stops receiving or responding to pings.   I have a Wrapper 
controlled app running on
a Win2k at home that has been up for about 7 weeks, so I don't think it 
is a time issue.

    I'll try and think of other ideas.

>>    The problem is that before the JVM is restarted, there are no 
>>messages from
>>the JVM about having received any packets.
>>    
>>
>
>
>I will go back through the logs and see when the wrapper behavior
>changed and will see if it correlates with any events on the application
>side.
>
Great, let me know what you find out.

>>collection by adding the -Xincgc.   I was not sure what the
>>-XX:+UseConcMarkSweepGC option does?
>>    
>>
>
>
>A couple of months ago, we had some major memory/garbage collection
>issues. After investigation we have found that for our application:
>
>1. When using the default garbage collector, if a major collection is
>performed while some of the JVM is sitting in the paging file, the GC
>times can increase up to 2 orders of magnitude. We were getting some 80
>- 90 second garbage collections! Doubling the RAM solved this problem.
>
>2. We made further improvements in our GC times by using a GC strategy
>that is new to 1.4.2, the Concurrent Low Pause collector. There is lots
>of information out there about the new GC strategies. One of the better
>ones is here: http://java.sun.com/docs/hotspot/gc1.4.2/. From that web
>page, it says to: "Use the concurrent low pause collector if your
>application would benefit from shorter garbage collector pauses and can
>afford to share processor resources with the garbage collector when the
>application is running." I could be wrong, but I am pretty sure that
>time in GC is not the issue here.
>
    Thanks always more things to study up on....  Thanks for the link.

> 
>
>>Also try extending your wrapper.ping.timeout to around 300, 5 
>>minutes.  
>>If the
>>problem is GC related, that will hopefully be long enough to make the 
>>problem
>>go away.   If the problem is GC related, then your 
>>application would be
>>unresponsive to its clients and not just the Wrapper during this time 
>>however,
>>have you seen such problems?
>>    
>>
>
>
>I would rather not do that right now. It feels to me like there is some
>problem between the wrapper and the application. The application is not
>working hard and I don't think it is experiencing major GC pauses.
>Because it happens so infrequently I would like to do that as a last
>resort because I won't be comfortable that the issue is fixed for a
>while.
>
Ok, I'll try to think of some other causes.  That is the only thing in 
the logs right now so it
is what first comes to mind...

>>    I can't think of anything off hand that I have fixed 
>>since version 
>>3.0.2 that would
>>affect this, but there have been lots of improvements to the wrapper. 
>>You may want
>>to consider upgrading to version 3.0.5
>>    
>>
>
>
>We can upgrade on a future version, however the application is part of a
>medical device that has tight FDA constraints. We could change the
>version, but it would be a lot of work. There would be documentation to
>change, and even worse, we would have to rerun many tests. If we knew it
>would fix the problem, then we would go ahead and do it. Otherwise, I
>don't want to change.
>
Ok, go ahead and stick with 3.0.2 for now.  I don't think there were any 
changes
that would affect this anyway.

You can play with the ping timeout in your version.   But if you use the 
latest version, you
can also change the actual ping interval.  May be useful.

Cheers,
Leif

[Wrapper-user] RE: Re: libwrapper.so fails to load under HP-UX

[EXT-Smith, E. M <eri...@bo...>]

Leif,

(I tried sending this to you directly, but SF rejected it.  Don't know =
why)

As I promissed, here is the Makefile I used to get the wrapper compiling =
and loading the libwrapper.sl file under HP-UX 11.0.
We used the following versions of software:
	java 	- 1.4.1_05
	gcc  	- 3.2.3
	HP-UX - HP-UX B.11.00

We still have a few issues, but they all appear to be in our code or the =
Java 1.4.1 VM.

Sincerely

Eric M. Smith
InfoStructure Systems
Boeing Chairman's Innovation Initiative

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Makefile.hpux
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
JNI_HEADERS =3D $(JAVA_HOME)/include
DEFS =3D -I$(JNI_HEADERS) -I$(JNI_HEADERS)/hp-ux

DEFVALS =3D -DHPUX -D_HPUX -D_POSIX_C_SOURCE=3D199506L =
-D_XOPEN_SOURCE_EXTENDED

OPTS =3D -ansi -fPIC

COMPILE =3D gcc -c $(DEFVALS) $(OPTS) $(DEFS)
COMPILE2 =3D cc -c $(DEFVALS) $(DEFS)
COMPILE_LINK =3D gcc $(DEFVALS) $(OPTS) $(DEFS)

LINK =3D ld
realpath_SOURCE =3D realpath.c
wrapper_SOURCE =3D wrapper.c wrapper_unix.c property.c logger.c
wrapper_OBJECTS =3D wrapper.o wrapper_unix.o property.o logger.o
libwrapper_sl_SOURCE =3D wrapperjni_unix.c wrapperjni.c
libwrapper_sl_OBJECTS =3D wrapperjni_unix.o wrapperjni.o
BIN =3D ../../bin
LIB =3D ../../lib

all: init realpath wrapper libwrapper.sl

clean:
	rm -f *.o

cleanall: clean
	rm -rf *~ .deps
	rm -f $(BIN)/realpath $(BIN)/wrapper $(LIB)/libwrapper.sl

init:
	if test ! -d .deps; then mkdir .deps; fi

realpath: $(realpath_SOURCE)
	$(COMPILE_LINK) $(realpath_SOURCE) -o $(BIN)/realpath

wrapper: $(wrapper_SOURCE)
	$(COMPILE_LINK) $(wrapper_SOURCE) -lm -o $(BIN)/wrapper

libwrapper.sl: $(libwrapper_so_OBJECTS)
	${COMPILE} $(libwrapper_sl_SOURCE)
	${LINK} $(libwrapper_sl_OBJECTS) -b -o $(LIB)/libwrapper.sl

%.o: %.c
	${COMPILE} ${OPTS} ${DEFS} $<

[Wrapper-user] RE: Re: Win2000 Service problem

[EXT-Smith, E. M <eri...@BO...>]

Stefan, Leif, et al.

Last evening I was trying to get our 7 services running under WinXP and =
discovered something that may be the underlying cause of a large number =
of problems on the Windows platforms.

It appeared when my service would start up properly as a console, but =
would not start as a service.

It comes down to the putenv()/getenv() calls in the wrapper_win.c file.

putenv() specifies :
   " Note that the string given to putenv must be static or global.  =
Unpredictable results will occur if a local or dynamic string given to =
putenv is used after the string memory is released. "
		(from Borland C++ Builder C Runtime Library Reference)

Within wrapper_win.c, the env buffer (used to pass info into putenv()) =
is local, reused, and removed from scope before the values are used.

For me, this appeared as an expected environment variable not being =
found during conf file resolution.

I made significant modifications to my version last evening to =
compensate for this.
I also changed some of the #ifdef values to use _DEBUG instead of DEBUG, =
and there are a few additional log_printf's that helped me find the =
problem.

Here's the DIFF.

407,408d405
<         log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_DEBUG, "Clearing up =
old command line"); <         log_printf(WRAPPER_SOURCE_WRAPPER, =
LEVEL_DEBUG, "Old Command Line \"%s\"", wrapperData->jvmCommand); =
417,419c414
<  < #ifdef _DEBUG <     log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_DEBUG, =
"JVM Command Line Parameters"); ---
>     /*
421c416
<         log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_DEBUG, "%d : %s", i, =
strings[i]); ---
>         printf("%d : %s\n", i, strings[i]);
423c418
< #endif ---
>     */
1021c1016
< #ifdef _DEBUG ---
> #ifdef DEBUG
1201,1202d1195
< static char **envKeys =3D NULL; < static int envKeysCount =3D 0; =
1204d1196
<     int envCount =3D 0; 1216c1208
< //    CHAR env[MAX_PROPERTY_NAME_LENGTH - 1 + =
MAX_PROPERTY_VALUE_LENGTH - 1 + 2]; ---
>     CHAR env[MAX_PROPERTY_NAME_LENGTH - 1 + MAX_PROPERTY_VALUE_LENGTH =
- 1 + 2];
1220c1212
< #ifdef _DEBUG ---
> #ifdef DEBUG
1235,1261d1225
<  <         // First time through, count all of the keys. <         do =
{ <             cbName =3D MAX_PROPERTY_NAME_LENGTH; <             =
cbData =3D MAX_PROPERTY_VALUE_LENGTH; <             err =3D =
RegEnumValue(hKey, dwIndex, name, &cbName, NULL, &type, data, &cbData); =
<             dwIndex++; <         } while (err !=3D =
ERROR_NO_MORE_ITEMS); <  <         if ( 0 < dwIndex ) { <             // =
Now allocate a buffer for the environment strings. <             if ( =
NULL !=3D envKeys ) { <                 int x =3D 0; <                 =
for ( x =3D 0; x < envKeysCount; x++ ) { <                     if ( NULL =
!=3D envKeys[ x ] ) { <                         free( envKeys[ x ] ); <  =
                       envKeys[ x ] =3D NULL; <                     } <  =
               } <                 free( envKeys ); <                 =
envKeys =3D NULL; <             } <             envKeys =3D =
calloc(dwIndex, sizeof( char * ) ); <             envKeysCount =3D =
dwIndex; <         } <         if ( NULL !=3D *envKeys ) { <             =
dwIndex =3D 0; 1267c1231
< #ifdef _DEBUG ---
> #ifdef DEBUG
1271,1274c1235,1236
<                     envKeys[ dwIndex ] =3D =
malloc(MAX_PROPERTY_NAME_LENGTH - 1 + MAX_PROPERTY_VALUE_LENGTH - 1 + =
2); <                     if ( NULL !=3D envKeys[ dwIndex ] ) { <        =
                 sprintf(envKeys[ dwIndex ], "%s=3D%s", name, data); <   =
                      if (putenv(envKeys[ dwIndex ] ) ) { ---
>                 sprintf(env, "%s=3D%s", name, data);
>                 if (putenv(env)) {
1279c1241
< #ifdef _DEBUG ---
> #ifdef DEBUG
1282d1243
<                     } 1292d1252
<         } 1295c1255
< #ifdef _DEBUG ---
> #ifdef DEBUG
1311c1271
< #ifdef _DEBUG ---
> #ifdef DEBUG
1316c1276
< #ifdef _DEBUG ---
> #ifdef DEBUG
1320c1280
< #ifdef _DEBUG ---
> #ifdef DEBUG
1333c1293
< #ifdef _DEBUG ---
> #ifdef DEBUG
1339c1299
< #ifdef _DEBUG ---
> #ifdef DEBUG
1342,1344c1302,1303
<                                     // Replace the env string. <       =
                              sprintf(envKeys[ dwIndex ], "%s=3D%s", =
name, data); <                                     if (putenv(envKeys[ =
dwIndex ])) { ---
>                                     sprintf(env, "%s=3D%s", name, =
data);
>                                     if (putenv(env)) {
1362c1321
< #ifdef _DEBUG ---
> #ifdef DEBUG
1369c1328
< #ifdef _DEBUG ---
> #ifdef DEBUG
1904c1863
< #ifdef _DEBUG ---
> #ifdef DEBUG
1912c1871
< #ifdef _DEBUG ---
> #ifdef DEBUG


Eric M. Smith
InfoStructure Systems
Boeing Chairman's Innovation Initiative

RE: [Wrapper-user] Occasional wrapper restart under light load

[Bill L. <bli...@to...>]

Hi Leif-

Thanks again for your attention with this issue. I have sent the zipped
up logs in a separate email. Please find my answers to your questions
below, inline.

-Bill Littman

> -----Original Message-----
> From: Leif Mortenson [mailto:le...@ta...]=20
> Sent: Thursday, October 16, 2003 10:19 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Occasional wrapper restart under=20
> light load
>=20
>=20
> Bill,
>     Could you zip up your full unmodified wrapper.log file=20
> and send it=20
> to me directly?
> Most likely too big for the list.  I want to compare the output when=20
> things are going
> smoothly to that just before it fails.
>=20
>     For some reason, the JVM stops replying to ping requests from the=20
> Wrapper.
> After the ping timeout expires, it gives up and restarts the JVM.
>     A normal ping cycle looks like the following:
> DEBUG  | wrapperp | 2003/10/14 10:43:19 | send a packet 103 : ping
> INFO   | jvm 2    | 2003/10/14 10:43:19 | Received a packet 103 : ping
> INFO   | jvm 2    | 2003/10/14 10:43:19 | Send a packet 103 : ok
> DEBUG  | wrapperp | 2003/10/14 10:43:19 | read a packet 103 : ok
> DEBUG  | wrapper  | 2003/10/14 10:43:19 | Got ping response from JVM
>=20
>     The problem is that before the JVM is restarted, there are no=20
> messages from
> the JVM about having received any packets.


I will go back through the logs and see when the wrapper behavior
changed and will see if it correlates with any events on the application
side.


>     You are using close to 500MB of memory.  I have seen the=20
> JVM take a very
> long time to do a single garbage collection sweep.   When this is=20
> happening, the
> %CPU in the task manager does not always show the system as=20
> being all that
> busy.   If this is the problem you might want to try using=20
> incremental=20
> garbage
> collection by adding the -Xincgc.   I was not sure what the
> -XX:+UseConcMarkSweepGC option does?


A couple of months ago, we had some major memory/garbage collection
issues. After investigation we have found that for our application:

1. When using the default garbage collector, if a major collection is
performed while some of the JVM is sitting in the paging file, the GC
times can increase up to 2 orders of magnitude. We were getting some 80
- 90 second garbage collections! Doubling the RAM solved this problem.

2. We made further improvements in our GC times by using a GC strategy
that is new to 1.4.2, the Concurrent Low Pause collector. There is lots
of information out there about the new GC strategies. One of the better
ones is here: http://java.sun.com/docs/hotspot/gc1.4.2/. From that web
page, it says to: "Use the concurrent low pause collector if your
application would benefit from shorter garbage collector pauses and can
afford to share processor resources with the garbage collector when the
application is running." I could be wrong, but I am pretty sure that
time in GC is not the issue here.


> Also try extending your wrapper.ping.timeout to around 300, 5=20
> minutes. =20
> If the
> problem is GC related, that will hopefully be long enough to make the=20
> problem
> go away.   If the problem is GC related, then your=20
> application would be
> unresponsive to its clients and not just the Wrapper during this time=20
> however,
> have you seen such problems?


I would rather not do that right now. It feels to me like there is some
problem between the wrapper and the application. The application is not
working hard and I don't think it is experiencing major GC pauses.
Because it happens so infrequently I would like to do that as a last
resort because I won't be comfortable that the issue is fixed for a
while.


>     I can't think of anything off hand that I have fixed=20
> since version=20
> 3.0.2 that would
> affect this, but there have been lots of improvements to the wrapper.=20
> You may want
> to consider upgrading to version 3.0.5


We can upgrade on a future version, however the application is part of a
medical device that has tight FDA constraints. We could change the
version, but it would be a lot of work. There would be documentation to
change, and even worse, we would have to rerun many tests. If we knew it
would fix the problem, then we would go ahead and do it. Otherwise, I
don't want to change.


> Cheers,
> Leif
>=20
> Bill Littman wrote:
>=20
> >Hi-
> >
> >I have an application running on Windows 2000. It has dual=20
> Xeons and 2
> >Gigs of memory. I am using Sun Java JRE 1.4.1_02 and Wrapper version
> >3.0.2.
> >
> >My application is a CORBA server serving data from a local=20
> DB2 database.
> >The ORB we use is OpenORB 1.3.0.
> >
> >Very occasionally the wrapper restarts the application while the
> >application is under very little load. There is no reason I=20
> can think of
> >why it would do this. I am pretty sure that the application is not
> >running out of resources. Memory usage appears to be fine=20
> and the number
> >of allocated threads appears bounded. The amount of time from
> >application start to when this problem occurs is not constant and can
> >vary wildly.
> >
> >I have attached my config files. A few notes on the config files:
> >
> >1. When this started, I added the lines: wrapper.ping.timeout=3D180 =
and
> >wrapper.cpu.timeout=3D30. This restart occurs so infrequently=20
> that it is
> >impossible to tell if this helps. As the last restart shows,=20
> it does not
> >solve the problem.
> >
> >2. Just recently, I changed the wrapper.logfile.loglevel to DEBUG and
> >added the line: =
wrapper.request_thread_dump_on_failed_jvm_exit=3DTRUE.
> >
> >3. One of the JVM flags, -Xloggc:C:\Tomo\Logs\GC.log, sends garbage
> >collection traces out to a log. There is a JVM bug where some of the
> >messages are sent to the console instead of the log file.=20
> Those messages
> >end up in the wrapper log produced by the application.
> >
> >So, from the attached wrapper log, here is the last two=20
> pings followed
> >by the error handling traces, with the garbage collection traces
> >removed.
> >
> >DEBUG  | wrapperp | 2003/10/14 10:42:51 | send a packet 103 : ping
> >DEBUG  | wrapperp | 2003/10/14 10:42:57 | send a packet 103 : ping
> >ERROR  | wrapper  | 2003/10/14 10:43:03 | JVM appears hung: Timed out
> >waiting for signal from JVM.
> >STATUS | wrapper  | 2003/10/14 10:43:03 | Dumping JVM state.
> >DEBUG  | wrapper  | 2003/10/14 10:43:03 | Sending BREAK=20
> event to process
> >group 2492.
> >ERROR  | wrapper  | 2003/10/14 10:43:03 | Unable to send=20
> BREAK event to
> >JVM process.  Err(6 : The handle is invalid. (0x6))
> >ERROR  | wrapper  | 2003/10/14 10:43:04 | Java Virtual=20
> Machine did not
> >exit on request, terminated
> >STATUS | wrapper  | 2003/10/14 10:43:10 | Launching a JVM...
> >
> >I am not sure what this means. Can someone help?
> >
> >Thank you.
> >
> >-Bill Littman
> > Lead Software Engineer
> > TomoTherapy, Inc.
> > 1240 Deming Way
> > Madison, WI  53717
> > Direct Phone: 608 824-2815
> > Phone: 608 824-2800
> > Fax: 608 824-2996
> > Web address: http://www.tomotherapy.com
> > Email: bli...@to...
> > =20
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>=20

Re: [Wrapper-user] Question on Unix

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

Ramachandra, Arun wrote:

> Well no.The behavior i observed was this:
> when i do kill -9 pid the wrapper stops,my JVM does not restart as i
> expected it to
>
Are you using the Wrapper's pid or the JVM's pid?

I just retested this and if I execute 'kill -9 wrapperpid', the Wrapper is
killed and the JVM exits as expected after about 30 seconds.

If I execute 'kill -9 jvmpid', the JVM is killed and the Wrapper restarts
it after 2-3 seconds.

This all appears to be correct.

Are you finding different results or doing something differently. Please
explain exactly what you are doing in more detail as it appears we are
seeing different results. I need to be able to reproduce what you are
seeing.

Cheers,
Leif

[Wrapper-user] Error occured when JNI code is executed

[Yasir K. <yas...@as...>]

Hi,

I downloaded Java Service Wrapper today and now trying to run my application using method 1 on windows 2000. My application interact with some of NT native functionality using JNI. Now problem is that when I start my application on clicking on the MyApp.bat file my application starts executing and execution fails when it tries to load a DLL with following exception (please note that I have not installed the service yet for my application) 

jvm 1    | System tray DLL error
jvm 1    | System tray ICON error
jvm 1    | java.lang.UnsatisfiedLinkError: nativeMoveToFront
jvm 1    |      at com.gc.systray.SystemTrayIconManager.nativeMoveToFront(Native Method)
jvm 1    |      at com.gc.systray.SystemTrayIconManager.<init>(SystemTrayIconManager.java:69)
jvm 1    |      at com.gc.systray.DefaultSystemTray.<init>(DefaultSystemTray.java:48)
jvm 1    |      at ASC_SplashScreen$2.run(ASC_SplashScreen.java:98)
jvm 1    |      at java.lang.Thread.run(Unknown Source)

Any ideas why JNI is not working properly?

Note: My application is running fine if I run it without using Wrapper.

Also I want to know that as my application is running under a wrapper, performance of my application will be affected, what u people say about performance issue?

Best Regards & Khuda Hafiz
Yasir Khan

RE: [Wrapper-user] Question on Unix

[Ramachandra, A. <Ram...@Sy...>]

Well no.The behavior i observed was this:
when i do kill -9 pid the wrapper stops,my JVM does not restart as i
expected it to


-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]
Sent: Friday, October 17, 2003 8:19 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Question on Unix


Arun,
I am not really clear on what you are asking here or the problem you may
be having. I am assuming you are using the script provided with the Wrapper.

If you start the wrapper using 'script.sh console' then the Wrapper will be
running in the current shell. Pressing CTRL-C will stop the Wrapper and its
JVM. You can also run 'script.sh stop' from another shell to stop the
Wrapper.

The alternative is to run as a daemon process by launching the Wrapper
with 'script.sh start'. If you use this method then CTRL-C will not
work. You
must use 'script.sh stop' to stop the Wrapper.

You mentioned using 'kill -9 pid'. If you kill the Wrapper process this way,
then the JVM process will be left running. It is designed to detect that the
Wrapper has died and will exit on its own within a minute. This is
expected and
correct behavior.
If you 'kill -9 pid' on the JVM. The Wrapper process will think that the
JVM crashed and will restart a new instance within a few seconds.

Hope this helps,

You have been getting lots of support lately. :-) If you have found it
useful,
please consider donating to the project to help pay for my time. Donations
are always appreciated and put to good use :-)
http://wrapper.tanukisoftware.org/doc/english/donate.html

Cheers,
Leif

Ramachandra, Arun wrote:

> >
> > I have managed to start the wrapper on Unix.
> > HOw do i test it?
> > If i press control-C or use kill -9 pid command it stops the jvm and
> does
> > not restart
> >
> > Platform i'm running it on: solaris
> > -Thanks
> > -Arun
> >
>
> Question on Unix-





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

RE: [Wrapper-user] Win 2000 Service problem

[Stefan M. <ste...@ea...>]

OK

Have killed off previous log files

Attached log file shows o/p from running InstallApp-NT.bat

Win2K Services
myService - set Log On As local admin
myService start

No additional entries in log file ?????


*******************Relevant contents of =
InstallApp-NT.bat*******************
rem
rem Run the application.
rem At runtime, the current directory will be that of Wrapper.exe
rem
:startup
"C:\wrapper_win32_3.0.5\bin\Wrapper.exe" -i
h:\com\eaac\HRWrapper\wrapper.conf
if not errorlevel 1 goto end
pause
*******************Relevant contents of =
InstallApp-NT.bat*******************



Regards
Stefan Maric
European Aviation Air Charter
01202 581111 x184

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: 2003-Oct-17 09:58
To: wra...@li...
Subject: Re: [Wrapper-user] Win 2000 Service problem

Stefan,
    You sent me lots of info, but skipped the one key piece that I need=20
to respond, the
log output of the run when you attempt to start the application as a=20
service.  Also.  When
sending in log files, please do not trim them down.  I know the idea is=20
to reduce the size of
the emails, but you removed a lot of the information that I wanted to=20
see. :-)

>If the InstallApp-NT.bat cannot use standard batch file commands for
setting
>up Env variables - Can you correct the example bat files=20
> =20
>
The environment variables declared in the scripts are only really meant=20
to be used
from within the batch files, not for references in the wrapper.conf=20
file.  So they are
correct in that sense.

Looking at your wrapper.conf file, I have one idea for what the problem=20
may be.
(It would be answered quickly by seeing the debug log output when you=20
attempt to
launch the Wrapper as a service.)

You have a few references to the WRAPPERDIR environment variable in your =

conf
file.  If you have not set this as a system level environment variable=20
or specified it on
the command line when the wrapper was installed as a service this will=20
not work:
wrapper.exe -i ../conf/wrapper.conf set.WRAPPERDIR=3DC:\MyApp

>wrapper.java.classpath.2=3D%WRAPPERDIR%/lib/wrapper.jar
>
>wrapper.java.library.path.1=3D%WRAPPERDIR%/lib
> =20
>
You might want to consider just using a relative path as follows:
wrapper.java.classpath.2=3D../lib/wrapper.jar
wrapper.java.library.path.1=3D../lib

Same goes for the following log location.  If that file can not be=20
accessed for any
reason then the wrapper will open a file called wrapper.log in the=20
windows system
directory.   That may be why you have not found the file this far.

>wrapper.logfile=3D%WKDIR%logs/HRScannerService.log
> =20
>
This could also be
wrapper.logfile=3D../logs/HRScannerService.log

Cheers,
Leif




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Win 2000 Service problem

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

Stefan,
    You sent me lots of info, but skipped the one key piece that I need 
to respond, the
log output of the run when you attempt to start the application as a 
service.  Also.  When
sending in log files, please do not trim them down.  I know the idea is 
to reduce the size of
the emails, but you removed a lot of the information that I wanted to 
see. :-)

>If the InstallApp-NT.bat cannot use standard batch file commands for setting
>up Env variables - Can you correct the example bat files 
>  
>
The environment variables declared in the scripts are only really meant 
to be used
from within the batch files, not for references in the wrapper.conf 
file.  So they are
correct in that sense.

Looking at your wrapper.conf file, I have one idea for what the problem 
may be.
(It would be answered quickly by seeing the debug log output when you 
attempt to
launch the Wrapper as a service.)

You have a few references to the WRAPPERDIR environment variable in your 
conf
file.  If you have not set this as a system level environment variable 
or specified it on
the command line when the wrapper was installed as a service this will 
not work:
wrapper.exe -i ../conf/wrapper.conf set.WRAPPERDIR=C:\MyApp

>wrapper.java.classpath.2=%WRAPPERDIR%/lib/wrapper.jar
>
>wrapper.java.library.path.1=%WRAPPERDIR%/lib
>  
>
You might want to consider just using a relative path as follows:
wrapper.java.classpath.2=../lib/wrapper.jar
wrapper.java.library.path.1=../lib

Same goes for the following log location.  If that file can not be 
accessed for any
reason then the wrapper will open a file called wrapper.log in the 
windows system
directory.   That may be why you have not found the file this far.

>wrapper.logfile=%WKDIR%logs/HRScannerService.log
>  
>
This could also be
wrapper.logfile=../logs/HRScannerService.log

Cheers,
Leif

RE: [Wrapper-user] Win 2000 Service problem

[Stefan M. <ste...@ea...>]

Thanks for your prompt reply

Please find attached my conf file & see below extracts from the log =
file(s)
Any help is greatly appreciated


Have set wrapper.debug=3Dtrue

****************Extract from App.bat************************************
STATUS | wrapper  | 2003/10/17 08:49:51 | --> Wrapper Started as Console
DEBUG  | wrapperp | 2003/10/17 08:49:51 | server listening on port =
32000.
STATUS | wrapper  | 2003/10/17 08:49:52 | Launching a JVM...
DEBUG  | wrapper  | 2003/10/17 08:49:52 | command: "C:\Program
Files\j2sdk_nb\j2sdk1.4.2\bin\java.exe" -Xms3m -Xmx64m
-Djava.library.path=3D"C:\wrapper_win32_3.0.5/lib" -classpath
"h:/;C:\wrapper_win32_3.0.5/lib/wrapper.jar;C:\jjtds\jtds-0.5.1.jar;C:\my=
SQL
\mysql-connector-java-3.0.8-stable\mysql-connector-java-3.0.8-stable-bin.=
jar
" -Dwrapper.key=3D"vjVwlS9DPWzT8ILN" -Dwrapper.port=3D32000
-Dwrapper.debug=3D"TRUE" -Dwrapper.cpu.timeout=3D"10" =
-Dwrapper.jvmid=3D1
com.eaac.HRWrapper.HRScannerService <myParam#1>...<myParam#n>
....
Loads of other INFO/DEBUG o/p
INFO   | jvm 1    | 2003/10/17 08:49:58 | scanHRForChanges
(above INFO line is expected periodic audit trail from within my app)
....
INFO   | jvm 1    | 2003/10/17 08:50:06 | scanHRForChanges
STATUS | wrapper  | 2003/10/17 08:50:07 | CTRL-C trapped.  Shutting =
down.
DEBUG  | wrapper  | 2003/10/17 08:50:07 | wrapperStopProcess(0) called.
....
INFO   | jvm 1    | 2003/10/17 08:50:08 | calling System.exit(0)
DEBUG  | wrapper  | 2003/10/17 08:50:08 | JVM exited normally.
STATUS | wrapper  | 2003/10/17 08:50:08 | <-- Wrapper Stopped
****************Extract from App.bat************************************


****************Extract from log file =
InstallApp-NT.bat*********************
DEBUG  | wrapper  | 2003/10/17 08:52:04 | Service command:
C:\wrapper_win32_3.0.5\bin\Wrapper.exe -s =
H:\com\eaac\HRWrapper\wrapper.conf
STATUS | wrapper  | 2003/10/17 08:52:05 | HR Web SSM Scanner installed.
STATUS | wrapper  | 2003/10/17 09:06:00 | HR Web SSM Scanner removed.
****************Extract from log file =
InstallApp-NT.bat*********************


*************Extract from log file =
InstallApp-NT.bat************************
(after hardcoding paths in InstallApp-NT.bat to avoid Env vars)

DEBUG  | wrapper  | 2003/10/17 09:07:22 | Service command:
C:\wrapper_win32_3.0.5\bin\Wrapper.exe -s =
h:\com\eaac\HRWrapper\wrapper.conf
STATUS | wrapper  | 2003/10/17 09:07:23 | HR Web SSM Scanner installed.
*************Extract from log file =
InstallApp-NT.bat************************


PLEASE NOTE
I have also tried your 'out-of-the-box'
	TestWrapper.bat & InstallTestWrapper-NT.bat
Same result




If the InstallApp-NT.bat cannot use standard batch file commands for =
setting
up Env variables - Can you correct the example bat files=20



Regards
Stefan Maric
European Aviation Air Charter
01202 581111 x184

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: 2003-Oct-17 03:37
To: wra...@li...
Subject: Re: [Wrapper-user] Win 2000 Service problem

Stefan,
    If your application is working as a console application, but failing =

when run as a service,
your problem is most likely related to a permissions issue or a=20
difference in the environment
variables that are available.

    In any case, the first thing you should do when debugging any=20
Wrapper problem is to
look in the wrapper.log file.   If nothing is obvious, try adding the=20
following property to your
wrapper.conf and then rerunning your application.
    wrapper.debug=3Dtrue

    This will cause the wrapper to dump, amongst other things, the full=20
java command line
used to actually launch Java.  Compare the command line used to launch=20
the application
as a service versus the one used to launch in console mode.

    The most common problem here is setting an environment variable in=20
the batch file
used to install and then run as a service.  Environment variables set in =

the batch file
will not be available when run as a service.  To do this, you need to=20
add them to the
command line used to install the Wrapper as a service.  As follows:

Wrapper.exe -i ..\conf\wrapper.conf set.MY_ENV=3Dtestval

    You can also define environment variables within the wrapper.conf=20
using the same
syntax.

    Post back whether or not you get things working.   If you are still=20
having problems,
then attach your wrapper.conf and the wrapper.log output from a SINGLE=20
run with
debug output enabled.

Cheers,
Leif




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] Problem with include in linux

[Daniel C. <dan...@gi...>]

Hi

I am using #include in a file called "wrapper_server.conf" to include a fil=
e named "wrapper.conf", both placed in the same directory as the executable=
. Everything works perfectly on windows but does not work att all on linux =
(Redhat 8.0, sun java 1.4.1_02-b06). I have tried wrapper 3.0.4 and 3.0.5.

I have tried moveing the include line around and rewritting it as:
#include wrapper.conf
# include wrapper.conf
#include ./wrapper.conf
#include /opt/fox/fox_f03/wrapper/wrapper.conf

Nothing works and I can't understand why. Has somebody successfully run inc=
ludes in linux? Does somebody know why it doesn't work?

Thanks

Daniel Carlsson=20
Gimlisoft AB
Email: dan...@gi...
Tel: 0709-744570, 031-189024

Re: [Wrapper-user] Does wrapper.jar differ between platforms?

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

Daniel,
    Currently, the releases for the various platforms are built on said 
platforms.
They are all built using the exact same source, but at different times 
etc and
using different JVM versions.  This can cause slight differences in the 
size of
the jar files produced on each platform.
    You should be able to use wrapper.jar file from any distribution 
with all
the rest however.  Personally I usually use the wrapper.jar from the Windows
distribution as that is my primary development machine.  But it 
shouldn't matter.

Cheers,
Leif

Daniel Carlsson wrote:

>Hi
>
>I noticed that wrapper.jar differs in the windows and linux releases in both version 3.0.4 and 3.0.5 (different size). Is something really different or are the differences just some different strings set at compile time or something?
>
>I am asking because a need to package an application that can be installed om both windows and linux and I wonder if a need both wrapper.jar's or just one.
>
>Med vänliga hälsningar
>
>Daniel Carlsson 
>Gimlisoft AB
>Email: dan...@gi...
>Tel: 0709-744570, 031-189024
>  
>

Re: [Wrapper-user] Occasional wrapper restart under light load

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

Bill,
    Could you zip up your full unmodified wrapper.log file and send it 
to me directly?
Most likely too big for the list.  I want to compare the output when 
things are going
smoothly to that just before it fails.

    For some reason, the JVM stops replying to ping requests from the 
Wrapper.
After the ping timeout expires, it gives up and restarts the JVM.
    A normal ping cycle looks like the following:
DEBUG  | wrapperp | 2003/10/14 10:43:19 | send a packet 103 : ping
INFO   | jvm 2    | 2003/10/14 10:43:19 | Received a packet 103 : ping
INFO   | jvm 2    | 2003/10/14 10:43:19 | Send a packet 103 : ok
DEBUG  | wrapperp | 2003/10/14 10:43:19 | read a packet 103 : ok
DEBUG  | wrapper  | 2003/10/14 10:43:19 | Got ping response from JVM

    The problem is that before the JVM is restarted, there are no 
messages from
the JVM about having received any packets.
    You are using close to 500MB of memory.  I have seen the JVM take a very
long time to do a single garbage collection sweep.   When this is 
happening, the
%CPU in the task manager does not always show the system as being all that
busy.   If this is the problem you might want to try using incremental 
garbage
collection by adding the -Xincgc.   I was not sure what the
-XX:+UseConcMarkSweepGC option does?
Also try extending your wrapper.ping.timeout to around 300, 5 minutes.  
If the
problem is GC related, that will hopefully be long enough to make the 
problem
go away.   If the problem is GC related, then your application would be
unresponsive to its clients and not just the Wrapper during this time 
however,
have you seen such problems?

    I can't think of anything off hand that I have fixed since version 
3.0.2 that would
affect this, but there have been lots of improvements to the wrapper. 
You may want
to consider upgrading to version 3.0.5

Cheers,
Leif

Bill Littman wrote:

>Hi-
>
>I have an application running on Windows 2000. It has dual Xeons and 2
>Gigs of memory. I am using Sun Java JRE 1.4.1_02 and Wrapper version
>3.0.2.
>
>My application is a CORBA server serving data from a local DB2 database.
>The ORB we use is OpenORB 1.3.0.
>
>Very occasionally the wrapper restarts the application while the
>application is under very little load. There is no reason I can think of
>why it would do this. I am pretty sure that the application is not
>running out of resources. Memory usage appears to be fine and the number
>of allocated threads appears bounded. The amount of time from
>application start to when this problem occurs is not constant and can
>vary wildly.
>
>I have attached my config files. A few notes on the config files:
>
>1. When this started, I added the lines: wrapper.ping.timeout=180 and
>wrapper.cpu.timeout=30. This restart occurs so infrequently that it is
>impossible to tell if this helps. As the last restart shows, it does not
>solve the problem.
>
>2. Just recently, I changed the wrapper.logfile.loglevel to DEBUG and
>added the line: wrapper.request_thread_dump_on_failed_jvm_exit=TRUE.
>
>3. One of the JVM flags, -Xloggc:C:\Tomo\Logs\GC.log, sends garbage
>collection traces out to a log. There is a JVM bug where some of the
>messages are sent to the console instead of the log file. Those messages
>end up in the wrapper log produced by the application.
>
>So, from the attached wrapper log, here is the last two pings followed
>by the error handling traces, with the garbage collection traces
>removed.
>
>DEBUG  | wrapperp | 2003/10/14 10:42:51 | send a packet 103 : ping
>DEBUG  | wrapperp | 2003/10/14 10:42:57 | send a packet 103 : ping
>ERROR  | wrapper  | 2003/10/14 10:43:03 | JVM appears hung: Timed out
>waiting for signal from JVM.
>STATUS | wrapper  | 2003/10/14 10:43:03 | Dumping JVM state.
>DEBUG  | wrapper  | 2003/10/14 10:43:03 | Sending BREAK event to process
>group 2492.
>ERROR  | wrapper  | 2003/10/14 10:43:03 | Unable to send BREAK event to
>JVM process.  Err(6 : The handle is invalid. (0x6))
>ERROR  | wrapper  | 2003/10/14 10:43:04 | Java Virtual Machine did not
>exit on request, terminated
>STATUS | wrapper  | 2003/10/14 10:43:10 | Launching a JVM...
>
>I am not sure what this means. Can someone help?
>
>Thank you.
>
>-Bill Littman
> Lead Software Engineer
> TomoTherapy, Inc.
> 1240 Deming Way
> Madison, WI  53717
> Direct Phone: 608 824-2815
> Phone: 608 824-2800
> Fax: 608 824-2996
> Web address: http://www.tomotherapy.com
> Email: bli...@to...
>  
>