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

[Wrapper-user] RE: Wrapper-user digest, Vol 1 #343 - 5 msgs

[Jan B. <jb...@pr...>]

> >>The code is all checked in to CVS if you would like to give it a try
> >>before the next release.  
> >>    
> >>
> >Sure, is there a way I can download a daily or weekly build? 
> (I cannot
> >find one on sourceforge and I'm not able to build any c/c++ 
> sources on
> >my windows machine)
> >  
> >
> That is because there are not any daily / weekly binary 
> builds.  I went 
> ahead and
> created snapshot and placed it up on the server.  You will 
> get a sneak 
> peek at the
> new documentation layout that will be in the next release.  (Still a 
> work in progress.)
> Be sure to read over the release notes as there are a lot of new 
> features in this
> release.
> 
> http://wrapper.tanukisoftware.org/tmp/wrapper_win32_3.1.0c.zip
> 
> Please post back to this list if you find any problems with this 
> snapshot.  Be sure
> to indicate the version being used.

With the WrapperSimpleApp it works like a charm :-)

STATUS | wrapper  | 2004/04/03 15:15:52 | --> Wrapper Started as Service
STATUS | wrapper  | 2004/04/03 15:15:52 | Launching a JVM...
INFO   | jvm 1    | 2004/04/03 15:15:53 | Wrapper (Version 3.1.0c)
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2004/04/03 15:15:53 | 
INFO   | jvm 1    | 2004/04/03 15:15:53 | Looking for servoy.properties
on C:\servoy.properties
INFO   | jvm 1    | 2004/04/03 15:15:53 | Loading servoy.properties from
C:\Program Files\Servoy\servoy.properties - Done
INFO   | jvm 1    | 2004/04/03 15:16:01 | Starting service
Tomcat-Standalone
INFO   | jvm 1    | 2004/04/03 15:16:01 | Apache Tomcat/4.0.1
INFO   | jvm 1    | 2004/04/03 15:16:03 | Starting service Tomcat-Apache
INFO   | jvm 1    | 2004/04/03 15:16:03 | Apache Tomcat/4.0.1
STATUS | wrapper  | 2004/04/03 15:16:42 | on_exit trigger matched.
Restarting the JVM.  (Exit code: 99)
STATUS | wrapper  | 2004/04/03 15:16:47 | Launching a JVM...
INFO   | jvm 2    | 2004/04/03 15:16:48 | Wrapper (Version 3.1.0c)
http://wrapper.tanukisoftware.org
INFO   | jvm 2    | 2004/04/03 15:16:48 | 
INFO   | jvm 2    | 2004/04/03 15:16:48 | Looking for servoy.properties
on C:\servoy.properties
INFO   | jvm 2    | 2004/04/03 15:16:48 | Loading servoy.properties from
C:\Program Files\Servoy\servoy.properties - Done
INFO   | jvm 2    | 2004/04/03 15:16:55 | Starting service
Tomcat-Standalone
INFO   | jvm 2    | 2004/04/03 15:16:55 | Apache Tomcat/4.0.1
INFO   | jvm 2    | 2004/04/03 15:16:58 | Starting service Tomcat-Apache
INFO   | jvm 2    | 2004/04/03 15:16:58 | Apache Tomcat/4.0.1
STATUS | wrapper  | 2004/04/03 15:17:58 | <-- Wrapper Stopped

But

With WrapperStartStopApp it's a bit strange

STATUS | wrapper  | 2004/04/03 14:17:01 | JVM did not exit on request,
terminated
STATUS | wrapper  | 2004/04/03 14:17:01 | on_exit trigger matched.
Restarting the JVM.  (Exit code: 1)
...
...
...
INFO   | jvm 2    | 2004/04/03 14:55:25 | <last error msg>
ERROR  | wrapper  | 2004/04/03 14:55:54 | Shutdown failed: Timed out
waiting for signal from JVM.
ERROR  | wrapper  | 2004/04/03 14:55:54 | JVM did not exit on request,
terminated
STATUS | wrapper  | 2004/04/03 14:55:55 | on_exit trigger matched.
Restarting the JVM.  (Exit code: 1)

So I noted 3 issues/ideas
1) the msg "JVM did not exit on request, terminated" could be extended
by how long is waited for exit... See following point.
2) wrapper.jvm_exit.timeout=60 seems not to work? There is not a delay
seen of one minute max between log lines
3) when the JVM is killed becouse it did not stop in time, my exit code
seems lost? I did stop with system.exit(99) and not with '1' as seen in
log line.


Regards Jan Blok

Re: [Wrapper-user] feature request: custom filter actions

[Everett T. <eve...@ne...>]

hi leif,

sorry about the late reply.

i'm running jboss as a service.  if any one of a number of exceptions occur 
i would like to use custom code to notify all clients that the server will 
restart in x minutes and then restart the service.

everett

At 10:13 AM Wednesday 3/31/2004, you wrote:
>Everett,
>Filters exist in the Wrapper code rather than in the JVM so classes can not be
>executed directly.
>It is not impossible however.  I could conceivably send a message back to 
>the JVM
>using the backend socket and then have the WrapperManager execute the required
>code.
>
>One option would be for you to do something like this yourself by 
>overriding the
>System.out and System.err PrintStreams.   Something like this:
>
>System.setOut( new FilterPrintStream( System.out ) );
>
>Your print stream would pass everything along to the original PrintStream 
>but then
>also check for your trigger strings.   This would not be able to trigger 
>off of low
>level output like the Wrapper can.  But it should work for most things.
>
>What exactly would you like to do that prompted you to request this feature?
>I may have some other ideas
>
>Cheers,
>Leif
>
>Everett Toews wrote:
>
>>hi leif,
>>
>>have you considered allowing users to create custom filter actions?
>>it might look something like:
>>
>>wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>>wrapper.filter.action.1=com.mycompany.MyFilterAction
>>
>>where com.mycompany.MyFilterAction is a class in a jar in the
>>classpath specified by wrapper.java.classpath.<n>.
>>
>>i realize this is a potential security issue.  if someone had access
>>to the app they could add triggers and execute arbitrary code against
>>anything else running in the jvm.   but if access isn't an
>>issue is this feature a possibility?
>>
>>everett

[Wrapper-user] Is the PATH separator set in a platform-independent manner?

[Scott W. R. <sr...@in...>]

Sorry if this is in the docs, I've been reading them
and the issue of the PATH separator is noticibly absent.
Sourceforge isn't allowing the user list to be searched right
now...

I need to set the PATH of the executing process to include
a specific directory where some native libraries will be
loaded from.  This is necessary because one library that
is loaded directly from Java code references other libraries
that subsequently cannot be found if they are not in the
PATH.  i.e. setting java.library.path isn't enough.

I want to do this:

set.PATH=%PATH%;%MYAPP_HOME%/lib

Does the Windows ';' path separator get translated correctly
on UNIX systems to a ':'?

Thanks,

Scott

Re: [Wrapper-user] JVM hang - Xms / Xmx

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

Leif Mortenson wrote:

> Looking at those docs means that I need to change the way I handle the 
> memory settings
> in the Wrapper.  Some of them require that the -Xms and -Xmx values 
> which are always
> set by the Wrapper not be set.

Ok, this is done.   3.1.0 will not pass memory parameters to the JVM if 
the init and
max properties are not specified in the wrapper.conf.   This means that 
you can also
now specify them manually using the wrapper.java.additional.<n> 
properties as well.

Cheers,
Leif

Re: [Wrapper-user] JVM hang - Xms / Xmx

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

Paul,

Paul Casanova wrote:

>Thanks for your info - I think I might have to buy a book and learn inside
>out about Java GC/memory usage.
>
>Our app takes around 950MB to start due to loading all the GIS stuff into
>RAM upon startup.  The application author's theory was that reading the GIS
>stuff from RAM is heaps faster than from disk and it has to be read into
>RAM at some stage (when used), so it might as well stay there!
>  
>
Not sure if this is an option.  But would is it possible to break the 
data up into
3 groups?
1) Data that is currently in use (stored in memory and on the local disk)
2) Data that is likely to be used (transfered and then stored to the 
local disk)
3) Other data (stored only on the remote server)

Net, is it possible to timestamp the data so you know when you need to 
obtain the
latest data from the remote server again?   If data has not changed then 
you could
continue using data stored on the disk.

This would increase the complexity of your app a bit (If it is even 
possible)  But should
reduce the memory footprint by quite a bit and also improve startup 
times, at least for
the second invocation of the application.

>Our app takes around 15 minutes to start on a fairly decent pair of boxes -
>the bottleneck is a gigabit Ethernet crossover cable running between the
>servers.  Our client has ordered a pair of fibre gigabit cards for each box
>and a managed fibre switch, but they haven't turned up yet.  The app takes
>6 minutes to start when app and DB are on the same box, but that's less
>scalable (HD / RAM capacity constraints).
>
>Due to the startup time, we don't want to do anything to extend startup -
>that's why we're happy to allocate a fair chunk to the initial memory.
>
>It's interesting though - I've noticed that since reducing the initial
>memory value, the peak memory usage (according to Windows anyway) tends to
>remain pretty darn close to the initial memory value.  This indicates that
>what you've outlined below seems to be working pretty well (ie when more
>RAM is needed, try a GC first).
>  
>
Good that sounds like you are seeing what I expected.  Just as an 
experiment.   Try
lowering the initial memory down to the default (3MB) and see how much of a
difference there is in your application's startup time.   Your app is 
much larger than
anything I have used.  But I have not seen all that large a difference 
when the app
is in the 512MB range.   I am interested to hear how significant the 
difference is.

This experiment will also give you a better understanding of how much 
memory the
application really needs and when that memory is needed.  Do this at the 
same time
as you have that memory logging background thread running.  You should 
then be
able to monitor how memory is allocated as your app is starting up and 
running.

>So what I've found is that by reducing the initial memory value in the
>config file, our JVM hasn't hung for the past 3 weeks.  This is a good
>sign.
>
>The problem that's now occurring more frequently is the
>java.lang.OutOfMemoryError, which indicates that at some stage the process
>needs more RAM than is available: either the GC fails or something else is
>going on.  And now that I think of it, we can't tell what the process maxes
>out at because by the time that I realise there's a problem the app has
>been restarted and Windows has lost the peak memory of the process that
>crashed (of course).
>  
>
I think it is fairly safe to assume that GC is working correctly.  Which 
means that
something in the application is actually eating up all available 
memory.   What
exactly that is yet to be determined.

1) The obvious is an object leak someplace.  These are easily located by 
adding the
following to your Wrapper.conf file:
  wrapper.java.additional.1=-Xrunhprof:depth=8
  wrapper.shutdown.timeout=0
This will increase the runtime memory usage some and also affects the 
performance of
the application.  But it should still be usable.  When you go to 
shutdown the JVM.  I
will appear to be locked up for quite a while as it writes out the 
profile data file.   I
have seen this take a couple minutes.  But I would not be surprised if 
it took 10
minutes for your application.   (That is the reason for the shutdown 
timeout setting.
We don't want the Wrapper killing the JVM as it tries to save all the 
data we worked
so hard to collect)

When the JVM exits you will see the following in the console or log file.
---
Dumping Java heap ... allocation sites ... done.
---

Look in the directory where Wrapper.exe is located and you will fine a 
file: java.hprof.txt
This file could be quite large, so I hope you have a good editor.

Search for "SITES BEGIN".  You will see a section toward the end of the 
file that looks
like this:
---
SITES BEGIN (ordered by live bytes) Fri Oct 11 12:56:48 2002
         percent         live       alloc'ed  stack class
rank   self  accum    bytes objs   bytes objs trace name
   1  6.80%  6.80%   544264 4779  544264 4779     0 [C
   2  2.78%  9.59%   222624  964  223280  966  6361 [C
   3  2.14% 11.73%   171248 1262  173504 1299     1 [C
   4  2.12% 13.85%   169368  106  169368  106 17124 [B
   5  2.08% 15.93%   166736  183  166736  183     0 [B
   6  1.71% 17.64%   136624  397  208088  796 17100 [C
   7  1.55% 19.18%   123664  435  123664  435 16788 [C
---
This section is ordered by how much memory is being used by objects which
were created at specific places in the code.  If you are lucky, the 
first row will
be a very large number.
The second to the last column is the Trace number.  This says where the 
objects
were created.   In the above example this is "4779".
To find out where these [C (Character Arrays) where created, do another 
search
for "TRACE 4779:"
I get the following:
---
TRACE 4779:
   java.lang.StringBuffer.toString(StringBuffer.java:1233)
   
org.apache.catalina.startup.Catalina.createContextCommon(Catalina.java:614)
   
org.apache.catalina.startup.Catalina.createStartMapperDefaultContext(Catalina.java:521) 

   
org.apache.catalina.startup.Catalina.createStartMapper(Catalina.java:391)
   org.apache.catalina.startup.Catalina.start(Catalina.java:722)
   org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
   org.apache.catalina.startup.Catalina.process(Catalina.java:179)
   
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:Native 
method)
---
You may find that you need to increase the stack depth, but that takes 
more memory
and I usually find a depth of 8 to be sufficient.

2) I have seen cases where synchronization errors in HotSpot compiled 
applications
have caused memory corruption.   In most cases, such corruption will 
cause the JVM
to crash, but in others it has simply resulted in a memory leak that 
doesn't show up
in the profiling output above.

I wonder about this second option because you are also experiencing JVM 
crashes.
These can be a real bi_ch to track down, so lets hope this is not the cause.
One way to check this is to try disabling the JIT/HotSpot compiler.  
Doing so will
often cause more Java like errors to start showing up as nothing has 
been optimized
into fast machine code.

>I've turned on some logging as suggested to dump out memory usage, so we'll
>see what this shows.
>
>Incidently, the most I've been able to allocate to Java (Xmx) is about
>1625MB on Windows 2000 Advanced Server.  On NT (previous platform) it was
>only about 1100MB - although that was with JDK 1.3.0, so that may have had
>an impact.  If I attempt starting with more than 1625MB, the app fails to
>start.  I think this is just a Java/Windows relationship thing.
>  
>
Looking at the following page, it looks like Java started supporting 
2GB+ heap sizes as
of 1.3.1.  You might want to give that a try.  There are also several 
command line
options described on this page which could interest you.
http://java.sun.com/docs/hotspot/ism.html

Looking at those docs means that I need to change the way I handle the 
memory settings
in the Wrapper.  Some of them require that the -Xms and -Xmx values 
which are always
set by the Wrapper not be set.

>The log files show the java.lang.OutOfMemoryError's for a while before the
>JVM eventually crashes.  Is there anyway to set up the Wrapper so that I
>can be notified (preferably by email) of this error so that I can remote
>takeover the box and have a look at things before the Wrapper restarts it?
>  
>
Not really at the moment.   What is triggering the JVM to be restarted now?
Have you registered an output trigger on the OutOfMemoryError console 
output?

If the Wrapper is killing the JVM because it stops responding to pings 
then you can
simply set the Ping timeout to 0.  This will not enable you to get an 
email, but it would
stop the JVM from restarting it.

Cheers,
Leif

Re: [Wrapper-user] RE: restarting the JVM with special exit code.

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

Jan,

>>Jan,
>>I liked this idea enough to go ahead and implement it this morning.
>>    
>>
>
>Wow, that's fast :-)
>  
>
We aim to please :-)

>>The code is all checked in to CVS if you would like to give it a try
>>before the next release.  
>>    
>>
>Sure, is there a way I can download a daily or weekly build? (I cannot
>find one on sourceforge and I'm not able to build any c/c++ sources on
>my windows machine)
>  
>
That is because there are not any daily / weekly binary builds.  I went 
ahead and
created snapshot and placed it up on the server.  You will get a sneak 
peek at the
new documentation layout that will be in the next release.  (Still a 
work in progress.)
Be sure to read over the release notes as there are a lot of new 
features in this
release.

http://wrapper.tanukisoftware.org/tmp/wrapper_win32_3.1.0c.zip

Please post back to this list if you find any problems with this 
snapshot.  Be sure
to indicate the version being used.

Cheers,
Leif

[Wrapper-user] RE: restarting the JVM with special exit code.

[Jan B. <jb...@pr...>]

Hi,

> From: Leif Mortenson <le...@ta...>
> Subject: Re: [Wrapper-user] restarting the JVM with special exit code?
> Reply-To: wra...@li...
> 
> Jan,
> I liked this idea enough to go ahead and implement it this morning.

Wow, that's fast :-)

> The code is all checked in to CVS if you would like to give it a try
> before the next release.  

Sure, is there a way I can download a daily or weekly build? (I cannot
find one on sourceforge and I'm not able to build any c/c++ sources on
my windows machine)

Regards Jan Blok

Re: [Wrapper-user] JVM hang - Xms / Xmx

[Paul C. <cas...@au...>]

Leif,

Thanks for your info - I think I might have to buy a book and learn inside
out about Java GC/memory usage.

Our app takes around 950MB to start due to loading all the GIS stuff into
RAM upon startup.  The application author's theory was that reading the GIS
stuff from RAM is heaps faster than from disk and it has to be read into
RAM at some stage (when used), so it might as well stay there!

Our app takes around 15 minutes to start on a fairly decent pair of boxes -
the bottleneck is a gigabit Ethernet crossover cable running between the
servers.  Our client has ordered a pair of fibre gigabit cards for each box
and a managed fibre switch, but they haven't turned up yet.  The app takes
6 minutes to start when app and DB are on the same box, but that's less
scalable (HD / RAM capacity constraints).

Due to the startup time, we don't want to do anything to extend startup -
that's why we're happy to allocate a fair chunk to the initial memory.

It's interesting though - I've noticed that since reducing the initial
memory value, the peak memory usage (according to Windows anyway) tends to
remain pretty darn close to the initial memory value.  This indicates that
what you've outlined below seems to be working pretty well (ie when more
RAM is needed, try a GC first).

So what I've found is that by reducing the initial memory value in the
config file, our JVM hasn't hung for the past 3 weeks.  This is a good
sign.

The problem that's now occurring more frequently is the
java.lang.OutOfMemoryError, which indicates that at some stage the process
needs more RAM than is available: either the GC fails or something else is
going on.  And now that I think of it, we can't tell what the process maxes
out at because by the time that I realise there's a problem the app has
been restarted and Windows has lost the peak memory of the process that
crashed (of course).

I've turned on some logging as suggested to dump out memory usage, so we'll
see what this shows.

Incidently, the most I've been able to allocate to Java (Xmx) is about
1625MB on Windows 2000 Advanced Server.  On NT (previous platform) it was
only about 1100MB - although that was with JDK 1.3.0, so that may have had
an impact.  If I attempt starting with more than 1625MB, the app fails to
start.  I think this is just a Java/Windows relationship thing.

The log files show the java.lang.OutOfMemoryError's for a while before the
JVM eventually crashes.  Is there anyway to set up the Wrapper so that I
can be notified (preferably by email) of this error so that I can remote
takeover the box and have a look at things before the Wrapper restarts it?

Regards,

Paul Casanova



|---------+---------------------------------------->
|         |           Leif Mortenson               |
|         |           <le...@ta...>    |
|         |           Sent by:                     |
|         |           wra...@li...|
|         |           ceforge.net                  |
|         |                                        |
|         |                                        |
|         |           31/03/2004 06:13 PM          |
|         |           Please respond to            |
|         |           wrapper-user                 |
|---------+---------------------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       wra...@li...                                                           |
  |       cc:                                                                                                    |
  |       Subject:  Re: [Wrapper-user] JVM hang - Xms / Xmx                                                      |
  >--------------------------------------------------------------------------------------------------------------|




Paul,
    Here is Java memory as I understand it. :-]

    As I understand it, the only reason to set the init memory value to
anything other than
the default is if you know that your application will always need a
certain amount of
memory on startup.  This will cause the JVM to allocate all of that
memory in one large
chunk rather than bit by bit as the application loads and initializes
all of its data.  This
can improve performance a bit.

    The JVM starts out with it allocated memory size set to the init
memory size.   If at
any point, the JVM needs more memory than it has allocated then it first
attempts to
do a GC.   If that fails then it will check to see if the allocated size
is less than the max
size.  If it is then another block of memory is allocated, thus
increasing the allocated
memory.  If the max size is hit then you will get an out of memory
exception.

    This amount of real memory on the system does not cause OutOfMemory
exceptions
unless the max size set when launching the JVM is larger than the total
Virtual memory
on the machine. If you start using swap memory however then performance
will be
severely degraded (not an issue with you)

    Each time a GC is performed, old memory will be freed up from the
allocated
memory.   As the JVM runs, its free memory will slowly decrease until
the above is
repeated.

    From what I have seen, once a block of memory is allocated from the
system it is
never returned.  So the allocated memory will stick at the largest size
since the JVM
was started.   (The exception appears to be 1.4.2  I have noticed that
it seems to
give memory back to the system?)

    Now, remember what I said about how the the JVM uses free memory
until it
is exhausted.  Well if that free memory is very large then the time
between GCs will
be long.  But the size of each GC will be quite large.  This appears to
cause a larger
hiccup in JVM performance.   For this reason, I usually try to keep the
init memory
small so that the free memory block is never any larger than is
absolutely needed.
This also makes sure that I don't use any more system memory than is
really needed.


    So what happens if you don't set the initmemory at all.  (Ie, leave
it at 3MB)
Your application should still work but it may not start up quite as
fast.  I am
wondering how much memory the application takes on startup.  Then what
happens to the memory over time.   It you have set the init memory to 1400
but it is still growing to 1600, this means that the application is
really requiring
that much memory.   This could be because of a leak or because you actually
need more than 1600MB.  What happens if you set it to 2000MB

    Are you familiar with the memory methods in the Runtime class?   Try
setting
up a thread in your program which logs the Allocated Memory, Free Memory,
and then via a little math, the in use memory to the console once per
minute or
so.   This will give you a much more accurate view of what is happening
memory
wise than you will get from watching the memory usage of Java in the Task
Manager.
    You may also want to call System.gc just before taking the memory
measurements to make sure you are looking at the memory usage without any
garbage in memory.

    I always use the Instrumentation package that I wrote for the Apache
Avalon
Excalibur project to monitor memory and other data over time.   It lets
you view
data like the images I attached.  Much easier to understand than log
output.  That
project is quite stable and well tested but at the moment it is lacking in
documentation.  Something I need to get around to doing.
http://avalon.apache.org/excalibur/index.html

More below.

Paul Casanova wrote:

>Thanks Leif.
>
>We have 6.3GB of RAM in a Win2K Advanced Server box - usually around 3GB
>free, so there's no chance of running out of physical RAM.
>
>We were using:
># Initial Java Heap Size (in MB)
>wrapper.java.initmemory=1600
>
># Maximum Java Heap Size (in MB)
>wrapper.java.maxmemory=1600
>
>
>Now using:
># Initial Java Heap Size (in MB)
>wrapper.java.initmemory=1400
>
># Maximum Java Heap Size (in MB)
>wrapper.java.maxmemory=1600
>
>When first trying the change, I tried initmemory=1200, then 1300, now 1400
>just to make sure it was functioning ok.  In the Windows Task Manager the
>Java process always peaked closed to each of these figures - never
exceeded
>1600MB as it did previously (used to get up to 1780MB: 1600MB + JVM
>overhead I assume).
>
>I've seen this hotspot error once before since switching to JSW (months
>back) - before hand it probably would have just been lost (svrany - MS
>product) - yay for JSW I say.
>
>Once again I don't seem to be able to find anything concrete about this
>error in Sun's Java forums, other than suggestions that native font dll's
>may have become corrupt - but then one would expect the error to occur
>regularly.  It happened twice in one day last week, and then today, with
>varying durations between the java.lang.OutOfMemoryError's and the JVM
>crash.  They've both been there each time though.
>
>
I am wondering if 1600MB is too small or if your application is leaking
memory?   It
would not be fun profiling an app that large. :-/

>We had always previously set the min and max heap values to the same.  I
>couldn't find much Sun info on how Xms and Xmx alter the behaviour of
>garbage collection (or any other behaviour for that matter) - only in
>http://java.sun.com/docs/hotspot/gc/.  I just gave it a whirl and it seems
>to have made a difference to the JVM hanging.
>
>
What changes did you make?

>I also read in one of the forums that issues with native calls from the
JVM
>were rectified in 1.4.1_02 +.  Have you also heard this?
>
>
I had not heard of any problems with earlier versions.

Cheers,
Leif




#### IM.png has been removed from this note on April 01, 2004 by Paul
Casanova

Re: [Wrapper-user] feature request: custom filter actions

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

Everett,
Filters exist in the Wrapper code rather than in the JVM so classes can 
not be
executed directly.
It is not impossible however.  I could conceivably send a message back 
to the JVM
using the backend socket and then have the WrapperManager execute the 
required
code.

One option would be for you to do something like this yourself by 
overriding the
System.out and System.err PrintStreams.   Something like this:

System.setOut( new FilterPrintStream( System.out ) );

Your print stream would pass everything along to the original 
PrintStream but then
also check for your trigger strings.   This would not be able to trigger 
off of low
level output like the Wrapper can.  But it should work for most things.

What exactly would you like to do that prompted you to request this feature?
I may have some other ideas

Cheers,
Leif

Everett Toews wrote:

> hi leif,
>
> have you considered allowing users to create custom filter actions?  
> it might look something like:
>
>wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>wrapper.filter.action.1=com.mycompany.MyFilterAction
>
>where com.mycompany.MyFilterAction is a class in a jar in the
>classpath specified by wrapper.java.classpath.<n>.
>
>i realize this is a potential security issue.  if someone had access
>to the app they could add triggers and execute arbitrary code against
>anything else running in the jvm.   but if access isn't an
>issue is this feature a possibility?
>
>everett
>

[Wrapper-user] feature request: custom filter actions

[Everett T. <eve...@ne...>]

hi leif,

have you considered allowing users to create custom filter actions?  it 
might look something like:

wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=com.mycompany.MyFilterAction

where com.mycompany.MyFilterAction is a class in a jar in the classpath 
specified by wrapper.java.classpath.<n>.

i realize this is a potential security issue.  if someone had access to the 
app they could add triggers and execute arbitrary code against anything 
else running in the jvm.   but if access isn't an issue is this feature a 
possibility?

everett

Re: [Wrapper-user] System.in can not be used when the JVM is being controlled by the Java Service

[Everett T. <eve...@ne...>]

At 06:46 PM Tuesday 3/30/2004, you wrote:
>Everett,
>    The feature to cause the System.in to block does not exist in 
> currently released
>versions of the Wrapper.  This will not be available until 3.1.0.  Are you 
>using a
>released version or building from CVS?
>
>    You could probably figure out what is going on a little better by 
> adding some
>print statements after the call to read from System.in.   But from looking 
>at your
>code and the log output, I am betting that you are using 3.0.5 or earlier and
>the call to System.in.read is throwing an IOException.   Your code is simply
>ignoring any exceptions thrown and continuing on.  Try printing out the 
>exception
>you are catching.

you're right, i'm using 3.0.5.  i should've mentioned that in my question.


>    Strong advice.  Never, and I mean Never! simply eat an exception.
>If you
>are 100% sure that code will never actually throw an exception then printing
>it out should never happen and will not hurt.   If you do encounter an 
>unexpected
>exception then you will save yourself hours of hair pulling trying to 
>figure out the
>problem.  :-)  Speaking from experience.

i agree completely.  it wasn't my code originally, i was just trying to 
turn it into a service, but i guess i'll have to make some changes...


>    Let me know if I was wrong in any of my assumptions, I had to guess 
> because
>you didn't post the version you are using.
>
>Cheers,
>Leif

thanks for the help,
everett 

Re: [Wrapper-user] JVM hang - Xms / Xmx

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

Paul,
    Here is Java memory as I understand it. :-]

    As I understand it, the only reason to set the init memory value to 
anything other than
the default is if you know that your application will always need a 
certain amount of
memory on startup.  This will cause the JVM to allocate all of that 
memory in one large
chunk rather than bit by bit as the application loads and initializes 
all of its data.  This
can improve performance a bit.

    The JVM starts out with it allocated memory size set to the init 
memory size.   If at
any point, the JVM needs more memory than it has allocated then it first 
attempts to
do a GC.   If that fails then it will check to see if the allocated size 
is less than the max
size.  If it is then another block of memory is allocated, thus 
increasing the allocated
memory.  If the max size is hit then you will get an out of memory 
exception.

    This amount of real memory on the system does not cause OutOfMemory 
exceptions
unless the max size set when launching the JVM is larger than the total 
Virtual memory
on the machine. If you start using swap memory however then performance 
will be
severely degraded (not an issue with you)

    Each time a GC is performed, old memory will be freed up from the 
allocated
memory.   As the JVM runs, its free memory will slowly decrease until 
the above is
repeated.

    From what I have seen, once a block of memory is allocated from the 
system it is
never returned.  So the allocated memory will stick at the largest size 
since the JVM
was started.   (The exception appears to be 1.4.2  I have noticed that 
it seems to
give memory back to the system?)

    Now, remember what I said about how the the JVM uses free memory 
until it
is exhausted.  Well if that free memory is very large then the time 
between GCs will
be long.  But the size of each GC will be quite large.  This appears to 
cause a larger
hiccup in JVM performance.   For this reason, I usually try to keep the 
init memory
small so that the free memory block is never any larger than is 
absolutely needed.
This also makes sure that I don't use any more system memory than is 
really needed.


    So what happens if you don't set the initmemory at all.  (Ie, leave 
it at 3MB)
Your application should still work but it may not start up quite as 
fast.  I am
wondering how much memory the application takes on startup.  Then what
happens to the memory over time.   It you have set the init memory to 1400
but it is still growing to 1600, this means that the application is 
really requiring
that much memory.   This could be because of a leak or because you actually
need more than 1600MB.  What happens if you set it to 2000MB

    Are you familiar with the memory methods in the Runtime class?   Try 
setting
up a thread in your program which logs the Allocated Memory, Free Memory,
and then via a little math, the in use memory to the console once per 
minute or
so.   This will give you a much more accurate view of what is happening 
memory
wise than you will get from watching the memory usage of Java in the Task
Manager.
    You may also want to call System.gc just before taking the memory
measurements to make sure you are looking at the memory usage without any
garbage in memory.

    I always use the Instrumentation package that I wrote for the Apache 
Avalon
Excalibur project to monitor memory and other data over time.   It lets 
you view
data like the images I attached.  Much easier to understand than log 
output.  That
project is quite stable and well tested but at the moment it is lacking in
documentation.  Something I need to get around to doing.
http://avalon.apache.org/excalibur/index.html

More below.

Paul Casanova wrote:

>Thanks Leif.
>
>We have 6.3GB of RAM in a Win2K Advanced Server box - usually around 3GB
>free, so there's no chance of running out of physical RAM.
>
>We were using:
># Initial Java Heap Size (in MB)
>wrapper.java.initmemory=1600
>
># Maximum Java Heap Size (in MB)
>wrapper.java.maxmemory=1600
>
>
>Now using:
># Initial Java Heap Size (in MB)
>wrapper.java.initmemory=1400
>
># Maximum Java Heap Size (in MB)
>wrapper.java.maxmemory=1600
>
>When first trying the change, I tried initmemory=1200, then 1300, now 1400
>just to make sure it was functioning ok.  In the Windows Task Manager the
>Java process always peaked closed to each of these figures - never exceeded
>1600MB as it did previously (used to get up to 1780MB: 1600MB + JVM
>overhead I assume).
>
>I've seen this hotspot error once before since switching to JSW (months
>back) - before hand it probably would have just been lost (svrany - MS
>product) - yay for JSW I say.
>
>Once again I don't seem to be able to find anything concrete about this
>error in Sun's Java forums, other than suggestions that native font dll's
>may have become corrupt - but then one would expect the error to occur
>regularly.  It happened twice in one day last week, and then today, with
>varying durations between the java.lang.OutOfMemoryError's and the JVM
>crash.  They've both been there each time though.
>  
>
I am wondering if 1600MB is too small or if your application is leaking 
memory?   It
would not be fun profiling an app that large. :-/

>We had always previously set the min and max heap values to the same.  I
>couldn't find much Sun info on how Xms and Xmx alter the behaviour of
>garbage collection (or any other behaviour for that matter) - only in
>http://java.sun.com/docs/hotspot/gc/.  I just gave it a whirl and it seems
>to have made a difference to the JVM hanging.
>  
>
What changes did you make?

>I also read in one of the forums that issues with native calls from the JVM
>were rectified in 1.4.1_02 +.  Have you also heard this?
>  
>
I had not heard of any problems with earlier versions.

Cheers,
Leif

Re: [Wrapper-user] JVM hang - Xms / Xmx

[Paul C. <cas...@au...>]

Thanks Leif.

We have 6.3GB of RAM in a Win2K Advanced Server box - usually around 3GB
free, so there's no chance of running out of physical RAM.

We were using:
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=1600

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


Now using:
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=1400

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

When first trying the change, I tried initmemory=1200, then 1300, now 1400
just to make sure it was functioning ok.  In the Windows Task Manager the
Java process always peaked closed to each of these figures - never exceeded
1600MB as it did previously (used to get up to 1780MB: 1600MB + JVM
overhead I assume).

I've seen this hotspot error once before since switching to JSW (months
back) - before hand it probably would have just been lost (svrany - MS
product) - yay for JSW I say.

Once again I don't seem to be able to find anything concrete about this
error in Sun's Java forums, other than suggestions that native font dll's
may have become corrupt - but then one would expect the error to occur
regularly.  It happened twice in one day last week, and then today, with
varying durations between the java.lang.OutOfMemoryError's and the JVM
crash.  They've both been there each time though.

We had always previously set the min and max heap values to the same.  I
couldn't find much Sun info on how Xms and Xmx alter the behaviour of
garbage collection (or any other behaviour for that matter) - only in
http://java.sun.com/docs/hotspot/gc/.  I just gave it a whirl and it seems
to have made a difference to the JVM hanging.

I also read in one of the forums that issues with native calls from the JVM
were rectified in 1.4.1_02 +.  Have you also heard this?

Regards,

Paul Casanova




|---------+---------------------------------------->
|         |           Leif Mortenson               |
|         |           <le...@ta...>    |
|         |           Sent by:                     |
|         |           wra...@li...|
|         |           ceforge.net                  |
|         |                                        |
|         |                                        |
|         |           31/03/2004 04:05 PM          |
|         |           Please respond to            |
|         |           wrapper-user                 |
|---------+---------------------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       wra...@li...                                                           |
  |       cc:                                                                                                    |
  |       Subject:  Re: [Wrapper-user] JVM hang - Xms / Xmx                                                      |
  >--------------------------------------------------------------------------------------------------------------|




Paul,

Paul Casanova wrote:

>We've had problems with our JVM hanging from time to time.  The Wrapper
>restarted it each time faithfully, which saved heartache and downtime.
>
>I started looking into the initial / maximum heap values, and while I
>couldn't find much info about how they relate to garbage collection, there
>were comments that suggested setting them to different values (rather than
>the same).  I did this, and the JVM hasn't hung in the past 3 weeks -
which
>is fantastic!
>
>
Thanks for commenting on that.  I don't usually set the initial and max
heap values to
the same thing.  But I have seen config files from users in the past
which have done so.

Where did you see that?  It may make sense to place a warning in the
documentation
as something to keep an eye out for.

>Has this worked for anyone else - or is anyone else having JVM hanging
>issues?
>
>What I have noticed is that we are now getting
>INFO   | jvm 1    | 2004/03/31 12:26:33 | java.lang.OutOfMemoryError
>
>
What are the values that you are using for your initial and max heap
sizes?   My
obvious answer is that it appears that your application is running out
of memory.
But that would be too obvious.

When you modified the values for the max and init heap sizes are you
sure that
you do not have any typos that would be causing the wrapper to use the
defaults.
Check the command used to launch java at the top of the wrapper log with
debug
output enabled.  Make sure they are what you expect.

How long has your application been running when you encounter this problem?
Does there appear to be a memory leak in the application?   I can't think
of
any reason why this would be working with the init and max heap sizes set
to
the same values, but not working when they differ...

I'll think about this more after I hear back from you.

Cheers,
Leif



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] JVM hang - Xms / Xmx

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

Paul,

Paul Casanova wrote:

>We've had problems with our JVM hanging from time to time.  The Wrapper
>restarted it each time faithfully, which saved heartache and downtime.
>
>I started looking into the initial / maximum heap values, and while I
>couldn't find much info about how they relate to garbage collection, there
>were comments that suggested setting them to different values (rather than
>the same).  I did this, and the JVM hasn't hung in the past 3 weeks - which
>is fantastic!
>  
>
Thanks for commenting on that.  I don't usually set the initial and max 
heap values to
the same thing.  But I have seen config files from users in the past 
which have done so.

Where did you see that?  It may make sense to place a warning in the 
documentation
as something to keep an eye out for.

>Has this worked for anyone else - or is anyone else having JVM hanging
>issues?
>
>What I have noticed is that we are now getting
>INFO   | jvm 1    | 2004/03/31 12:26:33 | java.lang.OutOfMemoryError
>  
>
What are the values that you are using for your initial and max heap 
sizes?   My
obvious answer is that it appears that your application is running out 
of memory.
But that would be too obvious.

When you modified the values for the max and init heap sizes are you 
sure that
you do not have any typos that would be causing the wrapper to use the 
defaults.
Check the command used to launch java at the top of the wrapper log with 
debug
output enabled.  Make sure they are what you expect.

How long has your application been running when you encounter this problem?
Does there appear to be a memory leak in the application?   I can't think of
any reason why this would be working with the init and max heap sizes set to
the same values, but not working when they differ...

I'll think about this more after I hear back from you.

Cheers,
Leif

[Wrapper-user] JVM hang - Xms / Xmx

[Paul C. <cas...@au...>]

Hi All,

We've had problems with our JVM hanging from time to time.  The Wrapper
restarted it each time faithfully, which saved heartache and downtime.

I started looking into the initial / maximum heap values, and while I
couldn't find much info about how they relate to garbage collection, there
were comments that suggested setting them to different values (rather than
the same).  I did this, and the JVM hasn't hung in the past 3 weeks - which
is fantastic!

Has this worked for anyone else - or is anyone else having JVM hanging
issues?

What I have noticed is that we are now getting
INFO   | jvm 1    | 2004/03/31 12:26:33 | java.lang.OutOfMemoryError

followed by some ok
INFO   | jvm 1    | 2004/03/31 12:32:25 | Received a packet PING : ping
INFO   | jvm 1    | 2004/03/31 12:32:25 | Send a packet PING : ok
DEBUG  | wrapperp | 2004/03/31 12:32:25 | read a packet PING : ok
DEBUG  | wrapper  | 2004/03/31 12:32:25 | Got ping response from JVM

and then later followed by the JVM exiting with the following:
INFO   | jvm 1    | 2004/03/31 12:32:31 | An unexpected exception has been
detected in native code outside the VM.
INFO   | jvm 1    | 2004/03/31 12:32:31 | Unexpected Signal :
EXCEPTION_ACCESS_VIOLATION occurred at PC=0x718872c4
INFO   | jvm 1    | 2004/03/31 12:32:31 | Function
name=Java_sun_awt_font_NativeFontWrapper_registerCompositeFont
INFO   | jvm 1    | 2004/03/31 12:32:31 | Library=D:\jdk1.3.1
_09\jre\bin\fontmanager.dll
INFO   | jvm 1    | 2004/03/31 12:32:31 |
INFO   | jvm 1    | 2004/03/31 12:32:31 | Current Java thread:
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.awt.font.NativeFontWrapper.drawStringIntDiscreteRaster(Native Method)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.java2d.loops.ICRDrawStringRasterContext.invoke(TextRendering.java:321)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.awt.image.BufferedImageGraphics2D.drawString(BufferedImageGraphics2D.java:1120)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2253)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
rcis.render.MI002RNDBAnnotation.paint(MI002RNDBAnnotation.java:124)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
rcis.render.MI002BackgroundRenderer.<init>(MI002BackgroundRenderer.java:253)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
rcis.render.MI002Renderer.<init>(MI002Renderer.java:73)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
rcis.map.MA001MemoryModel.getMapImage(MA001MemoryModel.java:249)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
java.lang.reflect.Method.invoke(Native Method)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.rmi.transport.Transport$1.run(Transport.java:147)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
java.security.AccessController.doPrivileged(Native Method)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.rmi.transport.Transport.serviceCall(Transport.java:143)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
INFO   | jvm 1    | 2004/03/31 12:32:31 |       at
java.lang.Thread.run(Thread.java:479)

Our application deals with GIS, which disperses GIF files to the clients,
or generates postscript files for plotting, which is where the drawString
is being used.

Has anyone else experienced similar issues?  This is one I'd like to
rectify.

PS: JDK 1.3.1_09 on Win2K Advanced Server.

Regards,

Paul Casanova

Re: [Wrapper-user] System.in can not be used when the JVM is being controlled by the Java Service

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

Everett,
    The feature to cause the System.in to block does not exist in 
currently released
versions of the Wrapper.  This will not be available until 3.1.0.  Are 
you using a
released version or building from CVS?

    You could probably figure out what is going on a little better by 
adding some
print statements after the call to read from System.in.   But from 
looking at your
code and the log output, I am betting that you are using 3.0.5 or 
earlier and
the call to System.in.read is throwing an IOException.   Your code is simply
ignoring any exceptions thrown and continuing on.  Try printing out the 
exception
you are catching.

    Strong advice.  Never, and I mean Never! simply eat an exception.   
If you
are 100% sure that code will never actually throw an exception then printing
it out should never happen and will not hurt.   If you do encounter an 
unexpected
exception then you will save yourself hours of hair pulling trying to 
figure out the
problem.  :-)  Speaking from experience.

    Let me know if I was wrong in any of my assumptions, I had to guess 
because
you didn't post the version you are using.

Cheers,
Leif

Everett Toews wrote:

> hi leif,
>
> this is exactly the behavior i'm looking for in an application i'm 
> wrapping.  but when i read from System.in it doesn't seem to block.  
> this is the code:
>
> // an observer process is started here
>
> System.out.println("Events and errors will be logged to the log file.");
> System.out.println("**** Press [Enter] to stop receiving messages. 
> ****");
> InputStream is = System.in;
> try
> {
>   // wait for user input to stop receiving messages
>   int x = is.read();
>   is.close();
> }
> catch (IOException e)
> {
> }
>
> // shutdown the observer process
> System.exit(0);
>
> i get the following output from the wrapper:
>
> // start up messages
> INFO   | 2004/03/30 16:35:22 | Events and errors will be logged to the 
> log file.
> INFO   | 2004/03/30 16:35:22 | **** Press [Enter] to stop receiving 
> messages. ****
> INFO   | 2004/03/30 16:35:22 | Wrapper Manager: ShutdownHook started
> INFO   | 2004/03/30 16:35:22 | Send a packet STOP : 0
> DEBUG  | 2004/03/30 16:35:22 | read a packet STOP : 0
> DEBUG  | 2004/03/30 16:35:22 | JVM requested a shutdown. (0)
> DEBUG  | 2004/03/30 16:35:22 | wrapperStopProcess(0) called.
> DEBUG  | 2004/03/30 16:35:22 | Sending stop signal to JVM
> DEBUG  | 2004/03/30 16:35:22 | send a packet STOP : NULL
> INFO   | 2004/03/30 16:35:22 | WrapperSimpleApp: start(args) end.  
> Main Completed=false, exitCode=null
> INFO   | 2004/03/30 16:35:22 | returned from listener.start()
> INFO   | 2004/03/30 16:35:22 | Send a packet STARTED :
> INFO   | 2004/03/30 16:35:22 | Received a packet STOP :
> DEBUG  | 2004/03/30 16:35:22 | read a packet STARTED :
> DEBUG  | 2004/03/30 16:35:22 | JVM signalled that it was started.
> INFO   | 2004/03/30 16:35:23 | Thread, Wrapper-Shutdown-Hook, handling 
> the shutdown process.
> INFO   | 2004/03/30 16:35:23 | calling listener.stop()
> INFO   | 2004/03/30 16:35:23 | WrapperSimpleApp: stop(0)
> INFO   | 2004/03/30 16:35:23 | returned from listener.stop()
> INFO   | 2004/03/30 16:35:23 | Send a packet STOPPED : 0
> DEBUG  | 2004/03/30 16:35:23 | read a packet STOPPED : 0
> DEBUG  | 2004/03/30 16:35:23 | JVM signalled that it was stopped.
> INFO   | 2004/03/30 16:35:23 | Closing socket.
> INFO   | 2004/03/30 16:35:23 | Closed socket: 
> java.net.SocketException: Socket operation on nonsocket: recv failed
> DEBUG  | 2004/03/30 16:35:23 | socket read no code (closed?).
> INFO   | 2004/03/30 16:35:24 | Server daemon shut down
> INFO   | 2004/03/30 16:35:24 | Wrapper Manager: ShutdownHook complete
> DEBUG  | 2004/03/30 16:35:24 | JVM exited normally.
> STATUS | 2004/03/30 16:35:24 | <-- Wrapper Stopped
>
> any idea why the call to read() isn't blocking?
>
> thanks,
> everett
>
> At 10:40 AM Saturday 3/27/2004, you wrote:
>
>> Barney,
>>    You are actually the second person this month to run into problems 
>> with the way I
>> had implemented this.
>>
>>    For a number of reasons, it is not possible for the System.in 
>> InputStream to be used
>> when running under the Java Service Wrapper.  Doing so was resulting 
>> in a very
>> cryptic exception from deep within Java.  To clear things up for 
>> users, I had replaced
>> that exception with one of my own which provided a more useful 
>> explanation of the
>> cause of the problem.
>>
>>    The problem now is that when users try to integrate various 
>> applications with the
>> Wrapper, some of those applications are making use of System.in.  
>> Even though
>> the console input is not actually being used in some cases, the above 
>> exception is
>> preventing those applications from being started.
>>
>>    I have modified the Wrapper so that rather than throwing an 
>> exception, calls to
>> read from System.in will now simply block forever.  By doing this 
>> applications that
>> make use of System.in will simply behave as if there is no console 
>> input.
>>
>>    Never the less.  I do have the Wrapper print the following message 
>> to the console
>> whenever a thread attempts to read from System.in.  I was worried 
>> that not doing
>> something would cause users endless hours of frustration as they 
>> tried to figure out
>> why they were unable to read any input.
>>
>> WARNING - System.in can not be used when the JVM is being controlled 
>> by the Java
>> Service Wrapper.  Calls will block indefinitely.
>>
>>    Let me know if you have any comments on this.  If no reasons why 
>> this would be
>> a problem pop up then this will be in the 3.1.0 release.
>>
>> Cheers,
>> Leif
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] System.in can not be used when the JVM is being controlled by the Java Service

[Everett T. <eve...@ne...>]

hi leif,

this is exactly the behavior i'm looking for in an application i'm 
wrapping.  but when i read from System.in it doesn't seem to block.  this 
is the code:

// an observer process is started here

System.out.println("Events and errors will be logged to the log file.");
System.out.println("**** Press [Enter] to stop receiving messages. ****");
InputStream is = System.in;
try
{
   // wait for user input to stop receiving messages
   int x = is.read();
   is.close();
}
catch (IOException e)
{
}

// shutdown the observer process
System.exit(0);

i get the following output from the wrapper:

// start up messages
INFO   | 2004/03/30 16:35:22 | Events and errors will be logged to the log 
file.
INFO   | 2004/03/30 16:35:22 | **** Press [Enter] to stop receiving 
messages. ****
INFO   | 2004/03/30 16:35:22 | Wrapper Manager: ShutdownHook started
INFO   | 2004/03/30 16:35:22 | Send a packet STOP : 0
DEBUG  | 2004/03/30 16:35:22 | read a packet STOP : 0
DEBUG  | 2004/03/30 16:35:22 | JVM requested a shutdown. (0)
DEBUG  | 2004/03/30 16:35:22 | wrapperStopProcess(0) called.
DEBUG  | 2004/03/30 16:35:22 | Sending stop signal to JVM
DEBUG  | 2004/03/30 16:35:22 | send a packet STOP : NULL
INFO   | 2004/03/30 16:35:22 | WrapperSimpleApp: start(args) end.  Main 
Completed=false, exitCode=null
INFO   | 2004/03/30 16:35:22 | returned from listener.start()
INFO   | 2004/03/30 16:35:22 | Send a packet STARTED :
INFO   | 2004/03/30 16:35:22 | Received a packet STOP :
DEBUG  | 2004/03/30 16:35:22 | read a packet STARTED :
DEBUG  | 2004/03/30 16:35:22 | JVM signalled that it was started.
INFO   | 2004/03/30 16:35:23 | Thread, Wrapper-Shutdown-Hook, handling the 
shutdown process.
INFO   | 2004/03/30 16:35:23 | calling listener.stop()
INFO   | 2004/03/30 16:35:23 | WrapperSimpleApp: stop(0)
INFO   | 2004/03/30 16:35:23 | returned from listener.stop()
INFO   | 2004/03/30 16:35:23 | Send a packet STOPPED : 0
DEBUG  | 2004/03/30 16:35:23 | read a packet STOPPED : 0
DEBUG  | 2004/03/30 16:35:23 | JVM signalled that it was stopped.
INFO   | 2004/03/30 16:35:23 | Closing socket.
INFO   | 2004/03/30 16:35:23 | Closed socket: java.net.SocketException: 
Socket operation on nonsocket: recv failed
DEBUG  | 2004/03/30 16:35:23 | socket read no code (closed?).
INFO   | 2004/03/30 16:35:24 | Server daemon shut down
INFO   | 2004/03/30 16:35:24 | Wrapper Manager: ShutdownHook complete
DEBUG  | 2004/03/30 16:35:24 | JVM exited normally.
STATUS | 2004/03/30 16:35:24 | <-- Wrapper Stopped

any idea why the call to read() isn't blocking?

thanks,
everett

At 10:40 AM Saturday 3/27/2004, you wrote:
>Barney,
>    You are actually the second person this month to run into problems 
> with the way I
>had implemented this.
>
>    For a number of reasons, it is not possible for the System.in 
> InputStream to be used
>when running under the Java Service Wrapper.  Doing so was resulting in a very
>cryptic exception from deep within Java.  To clear things up for users, I 
>had replaced
>that exception with one of my own which provided a more useful explanation 
>of the
>cause of the problem.
>
>    The problem now is that when users try to integrate various 
> applications with the
>Wrapper, some of those applications are making use of System.in.  Even though
>the console input is not actually being used in some cases, the above 
>exception is
>preventing those applications from being started.
>
>    I have modified the Wrapper so that rather than throwing an exception, 
> calls to
>read from System.in will now simply block forever.  By doing this 
>applications that
>make use of System.in will simply behave as if there is no console input.
>
>    Never the less.  I do have the Wrapper print the following message to 
> the console
>whenever a thread attempts to read from System.in.  I was worried that not 
>doing
>something would cause users endless hours of frustration as they tried to 
>figure out
>why they were unable to read any input.
>
>WARNING - System.in can not be used when the JVM is being controlled by 
>the Java
>Service Wrapper.  Calls will block indefinitely.
>
>    Let me know if you have any comments on this.  If no reasons why this 
> would be
>a problem pop up then this will be in the 3.1.0 release.
>
>Cheers,
>Leif

Re: [Wrapper-user] restarting the JVM with special exit code?

[Jennifer K. <jk...@si...>]

Leif,
this will help me too. thanks!! I will try to test to.
Jennifer
On Mar 27, 2004, at 9:15 AM, Leif Mortenson wrote:

> Jan,
> I liked this idea enough to go ahead and implement it this morning.
> Unfortunately it turned out to be a much more difficult task than I had
> originally anticipated.   The state engine of the Wrapper had been
> starting the shutdown of the Wrapper as soon as the JVM requested
> a stop.  This meant that it was not possible to recover and simply
> restart the JVM.
>
> Anyway, long story short.   I ended up doing a major rework of the
> Wrapper's state engine.  It is now much cleaner so all in all a good
> thing to have done.
>
> The code is all checked in to CVS if you would like to give it a try
> before the next release.  I spent most of the day implementing and
> then getting all of the possible failure modes tested.  I am pretty
> sure that I have all the bugs worked out.  But due to the scale of
> the changes and where they were in the code, I would appreciate
> any prerelease testing.
>
> You are now able to configure the Wrapper to restart a JVM on any
> exit code.
>
> The following will restart the JVM if exit codes 1 or 2 are returned.
> wrapper.on_exit.1=RESTART
> wrapper.on_exit.2=RESTART
>
> The following will restart the JVM for any code other than 0.
> wrapper.on_exit.default=RESTART
> wrapper.on_exit.0=SHUTDOWN
>
> Cheers,
> Leif
>
> Jan Blok wrote:
>
>> Hi,
>>  I see in the docs it is possible to request a restart with 
>> WrapperManager.restart(), but I cannot have a compile decency on the 
>> wrapper code.
>> So I wonder if it's possible to configure the wrapper so it catches a 
>> System.exit(X) where X == Y todo a restart?
>>  In my case I want a restart when I quit with System.exit(99)
>>  It would be awesome when I could specify:
>>  # Makes the wrapper restart when System.exit(99) is executed
>> wrapper.restart.on_exitcode=99
>>
>>
>> Kind Regards
>> Jan Blok
>> Servoy
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] System.in can not be used when the JVM is being controlled by the Java Service

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

Barney,
    You are actually the second person this month to run into problems 
with the way I
had implemented this.

    For a number of reasons, it is not possible for the System.in 
InputStream to be used
when running under the Java Service Wrapper.  Doing so was resulting in 
a very
cryptic exception from deep within Java.  To clear things up for users, 
I had replaced
that exception with one of my own which provided a more useful 
explanation of the
cause of the problem.

    The problem now is that when users try to integrate various 
applications with the
Wrapper, some of those applications are making use of System.in.  Even 
though
the console input is not actually being used in some cases, the above 
exception is
preventing those applications from being started.

    I have modified the Wrapper so that rather than throwing an 
exception, calls to
read from System.in will now simply block forever.  By doing this 
applications that
make use of System.in will simply behave as if there is no console input.

    Never the less.  I do have the Wrapper print the following message 
to the console
whenever a thread attempts to read from System.in.  I was worried that 
not doing
something would cause users endless hours of frustration as they tried 
to figure out
why they were unable to read any input.

WARNING - System.in can not be used when the JVM is being controlled by 
the Java
Service Wrapper.  Calls will block indefinitely.

    Let me know if you have any comments on this.  If no reasons why 
this would be
a problem pop up then this will be in the 3.1.0 release.

Cheers,
Leif

bar...@on... wrote:

>Hi,
>
>when I'm starting my application, I'm getting the message below in the
>logfile.
>How can I handle this ?
>
>The filesharing server runs almost complete, I only dont get
>userconnections. HTTP is ok, and server/server connections too.
>
>regards,
>Barney
>
>
>DEBUG  | wrapperp | 2004/03/22 08:19:01 | read a packet PING : ok
>DEBUG  | wrapper  | 2004/03/22 08:19:01 | Got ping response from JVM
>INFO   | jvm 1    | 2004/03/22 08:19:01 | 8:19:01 AM serverip:
>80.134.8.29
>INFO   | jvm 1    | 2004/03/22 08:19:02 | java.io.IOException: System.in
>can not be used when the JVM is being controlled by the Java Service
>Manager.
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>org.tanukisoftware.wrapper.WrapperManager$WrapperInputStream.read(WrapperManager.java:2062)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.io.InputStream.read(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>sun.nio.cs.StreamDecoder$CharsetSD.readBytes(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>sun.nio.cs.StreamDecoder$CharsetSD.implRead(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>sun.nio.cs.StreamDecoder.read(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.io.InputStreamReader.read(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.io.BufferedReader.fill(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.io.BufferedReader.readLine(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.io.BufferedReader.readLine(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>de.applejuicenet.server.Daemon.cancel(TRUX)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>de.applejuicenet.server.Daemon.main(TRUX)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.lang.reflect.Method.invoke(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:108)
>INFO   | jvm 1    | 2004/03/22 08:19:02 |       at
>java.lang.Thread.run(Unknown Source)
>INFO   | jvm 1    | 2004/03/22 08:19:02 | 8:19:02 AM shutdown server
>INFO   | jvm 1    | 2004/03/22 08:19:02 | WrapperSimpleApp: main method
>completed
>DEBUG  | wrapperp | 2004/03/22 08:19:07 | send a packet PING : ping
>  
>

Re: [Wrapper-user] JVM requests restart after Approx. 1 minute

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

Chris,
There was a bug in version 3.0.5 of the Wrapper where the ping timeout
was always 30 seconds for the first ping. Once a single ping had been
received then the configured value would be used. Everything else
about your configuration looks correct, so most likely that is the problem.

If you wish to try out the latest code before the next release you
can grab the source out of CVS. Except for the C compiler the build
system is all self contained.

I have also added a new "tick" based timer. It will be experimental and
thus disabled by default for the next release. I want to make sure it gets
more widespread testing before I recommend it for general use. But my
testing so far shows that it performs much more reliably under very high
system loads, so you should not need to modify any of the timeouts.
If you want to give this a try you can enable the new timer with the
following property:
wrapper.use_system_time=FALSE

Cheers,
Leif

Tech, Chris wrote:

> When my system is under a heavy load and I try to start my java app as
> a NT service the JVM requests a restart after one minute. I have set
> all the timeout properties to 0 so you would think it wouldn't be
> timing out. When the system is at normal load the app. running as a
> service executes correctly. Below is my configuration file for the
> wrapper. Any help would be of great appreciation.
>
> wrapper.java.command=C:\Program Files\Java\j2re1.4.1_02\bin\java
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> wrapper.java.library.path.1=C:\Program Files\bin\..\lib
> wrapper.java.initmemory=3
> wrapper.java.maxmemory=64
> wrapper.app.parameter.1=tools.ManagerService
> wrapper.app.parameter.2=JmsMonitor
> wrapper.console.format=PM
> wrapper.console.loglevel=INFO
> wrapper.logfile=C:\Program Files\bin\..\bin\Monitor.log
> wrapper.logfile.format=LPTM
> wrapper.logfile.loglevel=DEBUG
> wrapper.logfile.maxsize=5m
> wrapper.logfile.maxfiles=5
> wrapper.syslog.loglevel=NONE
> wrapper.jvm_exit.timeout=0
> wrapper.ping.timeout=0
> wrapper.startup.timeout=0
> wrapper.cpu.timeout=0
> wrapper.ntservice.name=ATMCP Monitor Manager JOSEJmsMonitor
> wrapper.ntservice.displayname=ATMCP Monitor Manager JOSEJmsMonitor
> wrapper.ntservice.description=ATMCP Monitor Manager JOSEJmsMonitor
> wrapper.ntservice.dependency.1=
> wrapper.ntservice.starttype=AUTO_START
> wrapper.ntservice.interactive=false
> wrapper.java.classpath.1=C:\Program Files\bin\..\lib\wrapper.jar
> wrapper.java.classpath.2=C:\Program Files\bin\..\lib
> wrapper.java.classpath.4=C:\Program Files\bin\..\..\lib\weblogic.jar
> wrapper.java.classpath.5=C:\Program Files\bin\..\lib\jconnect.jar
> wrapper.java.classpath.7=C:\Program Files\bin\..\lib\jRegistryKey.jar
>
> Thanks
>
> Chris
>

Re: [Wrapper-user] restarting the JVM with special exit code?

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

Jan,
I liked this idea enough to go ahead and implement it this morning.
Unfortunately it turned out to be a much more difficult task than I had
originally anticipated.   The state engine of the Wrapper had been
starting the shutdown of the Wrapper as soon as the JVM requested
a stop.  This meant that it was not possible to recover and simply
restart the JVM.

Anyway, long story short.   I ended up doing a major rework of the
Wrapper's state engine.  It is now much cleaner so all in all a good
thing to have done.

The code is all checked in to CVS if you would like to give it a try
before the next release.  I spent most of the day implementing and
then getting all of the possible failure modes tested.  I am pretty
sure that I have all the bugs worked out.  But due to the scale of
the changes and where they were in the code, I would appreciate
any prerelease testing.

You are now able to configure the Wrapper to restart a JVM on any
exit code.

The following will restart the JVM if exit codes 1 or 2 are returned.
wrapper.on_exit.1=RESTART
wrapper.on_exit.2=RESTART

The following will restart the JVM for any code other than 0.
wrapper.on_exit.default=RESTART
wrapper.on_exit.0=SHUTDOWN

Cheers,
Leif

Jan Blok wrote:

> Hi,
>  
> I see in the docs it is possible to request a restart 
> with WrapperManager.restart(), but I cannot have a compile decency on 
> the wrapper code.
> So I wonder if it's possible to configure the wrapper so it catches a 
> System.exit(X) where X == Y todo a restart?
>  
> In my case I want a restart when I quit with System.exit(99)
>  
> It would be awesome when I could specify:
>  
> # Makes the wrapper restart when System.exit(99) is executed
> wrapper.restart.on_exitcode=99
>
>
> Kind Regards
> Jan Blok
> Servoy

[Wrapper-user] RE: restarting the JVM with special exit code?

[Jan B. <jb...@pr...>]

Hi,
 
> I see in the docs it is possible to request a restart with
> WrapperManager.restart(), but I cannot have a compile decency on the
> wrapper code.
> So I wonder if it's possible to configure the wrapper so it catches a
> System.exit(X) where X == Y todo a restart?
>  
> In my case I want a restart when I quit with System.exit(99)
>  
> It would be awesome when I could specify:
>  
> # Makes the wrapper restart when System.exit(99) is executed
> wrapper.restart.on_exitcode=99
> 
>> Messageas far as i know System.exit () is terminal: no callbacks, no
>> override, and it does not even come back.
>> so use reflection instead and you won't have the compile-time 
>> dependency:
>> 
>>     final String wrapperManagerClassName =
>> "org.tanukisoftware.wrapper.WrapperManager";
>>     final Class wrapperManagerClass = ClassUtil.forName
>> (wrapperManagerClassName);
>>     final Method restartMethod = 
>> wrapperManagerClass.getDeclaredMethod (
>>       "restart",
>>       new Class [] {});
>>     restartMethod.invoke (null, new Object[] {});

To make myself more clear, I EXIT my application with special exit code,
the wrapper receives this exit code and if it is the code indicated in
the properties as restart code, it restarts the JVM.
The problem with "WrapperManager.restart()" is that my application can
also be started on the command line from a shell script which already
catches the exitcode and restarts the JVM, so in that case I'm not using
the wrapper (code) at all.

In my opinion is "System.exit(restart_code)" also more elegant than
"WrapperManager.restart()"...

Kind Regards
Jan Blok

Re: [Wrapper-user] wrapper debugging

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

Everett,
    I am not clear where exactly that error message is coming from.
Try avoiding the batch file all together to make sure that is not the 
problem.
What happens if you execute the Wrapper directly with the following command:
C:\MyAppDir\bin\Wrapper.exe -c ..\conf\wrapper.conf

    It might be helpful to copy exactly what you are getting in the 
console and
then posting it.

    As for the wrapper.debug property, that will only be useful if the 
Wrapper.exe
is being successfully executed.  I am not sure you are getting that far.
And as to it not being in the manual.  It used to be.  I had deprecated 
it long ago
in favor of setting the log levels to the various log targets.  But had 
kept it in for
backwards compatibility.  As it turns out, it is a very useful little 
property and I
always use for shorthand. I'll get it back into the manual.

Cheers,
Leif

Everett Toews wrote:

> i'm using java service wrapper 3.0.5 to turn a simple java app into a 
> windows 2000 service but i've hit a problem.  i follow the integration 
> method 1 steps but when i try App.bat i get a "The system cannot find 
> the path specified." error from windows.  i've echoed the _APP_HOME 
> and _WRAPPER_CONF environment variables in App.bat and they seem 
> fine.  how can i find out what the path is that is causing the problem?
>
> in the troubleshooting section of the website 
> (http://wrapper.tanukisoftware.org/doc/english/troubleshooting.html) 
> there is a subsection titled "My Application will not start. What can 
> I do to narrow down the problem?" that references a wrapper.debug 
> configuration property.  i've tried setting wrapper.debug=true and 
> wrapper.debug=DEBUG in wrapper.conf but get no additional output.  
> also, this property isn't listed in the "Configuration Properties" 
> section of the website 
> (http://wrapper.tanukisoftware.org/doc/english/properties.html).  is 
> there a way to get debugging output from java service wrapper?
>
> thanks,
> everett

[Wrapper-user] wrapper debugging

[Everett T. <eve...@ne...>]

hi all,

i'm using java service wrapper 3.0.5 to turn a simple java app into a 
windows 2000 service but i've hit a problem.  i follow the integration 
method 1 steps but when i try App.bat i get a "The system cannot find the 
path specified." error from windows.  i've echoed the _APP_HOME and 
_WRAPPER_CONF environment variables in App.bat and they seem fine.  how can 
i find out what the path is that is causing the problem?

in the troubleshooting section of the website 
(http://wrapper.tanukisoftware.org/doc/english/troubleshooting.html) there 
is a subsection titled "My Application will not start. What can I do to 
narrow down the problem?" that references a wrapper.debug configuration 
property.  i've tried setting wrapper.debug=true and wrapper.debug=DEBUG in 
wrapper.conf but get no additional output.  also, this property isn't 
listed in the "Configuration Properties" section of the website 
(http://wrapper.tanukisoftware.org/doc/english/properties.html).  is there 
a way to get debugging output from java service wrapper?

thanks,
everett

Re: [Wrapper-user] Wrapper as Linux daemon

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

Yuval,

Yuval Zantkeren wrote:

>I fixed the problem it was again as you said the java was not configure
>properly in the wrapper.conf file.
>  
>
Great glad you got things working.

>I have one more question, How do I debug the errors that I receive I see it
>like this in the log:
>INFO   | jvm 1    | 2004/03/22 20:04:27 | Error:
>java.lang.NullPointerException
>  
>
Where is the above message coming from?  I am pretty sure that is not 
from the
Wrapper code.   Most likely you have some code like the following:
try {
  // Do something that is broken
} catch ( Exception e ) {
    System.out.println( "Error: " + e );
}

The problem with the above is that it will tell you that you had an 
exception, but not
what it is.   If you want to get a stack trace, and you do, then you 
should do the
following.
try {
  // Do something that is broken
} catch ( Exception e ) {
    System.out.println( "Error: " + e );
    e.printStackTrace();
}

The stack trace will then let you find where in your program the 
exception is being
thrown.

Logging tools make the above a lot cleaner.


>how can I get more details about the error? If I configure
>wrapper.debug=true will help?
>  
>
It depends where the error is coming from.  setting debug to true only 
helps with Wrapper
related problems.  The above was in your log file anyways wasn't it?

Cheers,
Leif