Re: [Wrapper-user] Wrapper notification...

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

Luis,
    I'll try to think of a clean way to add the support you are asking 
for.  I am worried about
whether or not it will be possible in a reasonable cross platform way 
without adding too
much complexity to the wrapper's config file.  I'll try a few things out 
though.

    In the mean time, would it be possible to create a method that is 
called whenever your
application is first launched.  This method would first call 
WrapperManager.getJVMId to
find out if the JVM has been restarted.  If so, it would load in say the 
last 100 lines of the
wrapper.log file.  Then send the contents to a system administrator 
using java mail.  That
should reliably let your sysadmin know whenever a JVM is restarted.

    Doing this kind of thing from within Java is pretty easy.  Doing it 
from within the
Wrapper, in C, doesn't sound like too much fun.  I could probably get it 
working by
linking in a third party library but that would have the effect of 
increasing the size of
the Wrapper binary, most likely by quite a bit

    If I set something to simply execute an external command, it would 
give the most
flexibility.   But then it would be entirely up to the user to implement 
things like
mail notifications.

>Yes tell me about it.  What we run is a backend / app / client
>environment, and our app does a lot of number crunching which requires a
>lot of system for just one client environment.  One of our client has 2
>environment, one prod and the second is their test env which they test
>our new releases.  This totals about 30 machines.   Plus our own
>environments for testing and for our other clients givings us the grand
>total of about 80 machines.  
>We use JBoss as our platform env.  Well to put it simple terms.  With
>the exception of the app servers, the computing jobs are sent to servers
>running several instances of the wrapper launching separate JVMs.  Our
>app isn't multi threaded to handle multiple jobs due to memory
>constraints with the data that is handled.  When that happens, which
>won't be in the near future, there would only be 1 instance.  So we need
>to have separate JVMs.  As you can see, I how truly happy I was to find
>the wrapper and made every effort to support the software.  This has
>made my job easier to script stopping and starting services and
>monitoring.
>
    Glad to be able to help out.  That is a large system.   I have one 
customer running an
application that is distributed across about 20 systems.  A combination 
of Windows,
and Solaris.  Each of these systems uses less than 128MB so it is a 
different scale.
Some of the same issues with keeping them all up and monitored however.  
So far the
JVMs have all been quite stable though.  I have not heard of even one of 
them being
restarted over the last year.   It would be nice to have a system set up 
to get notification
if and when one of them ever does restart however.

>We already use log4j to manage our systems logging, etc.. but the issue
>arises with getting notification when a jvm dies due to out of memory
>errors, where log4j dies with that jvm.
>  
>
True, the out of memory errors are displayed at a much lower level so I 
don't think that
log4j would be able to catch them.  (?)  Not sure about the case where 
the stdout/err
PrintStreams have been replaced with user classes.

>As I read from the previous email, I'm guessing my option of the wrapper
>on filter.action=shutdown, would not invoke the NT service recovery.  Is
>this correct or did I misread?
>  
>
True, I have not used the NT service recovery feature personally, but I 
doubt it would
work.   I imagine that it is only monitoring the service process.  When 
that exits, it takes
some action.  In this case the Wrapper is the service process.  The JVM 
is just a child
process of the Wrapper, so I doubt the monitor is even aware it exists.

>So back to the discussion, I can see the issue of supporting multiple
>events.  But since the focus of the wrapper is running jvm as service
>and providing reliability, this should be limited to events that are not
>controllable within a JVM which usually turns out to be a JVM shutdown.
>This should be supported by allowing executing a system call, keeping
>the changes to the wrapper to a minimal.
>  
>
Lets hear any more ideas and I'll give it some more thought as well.

Cheers,
Leif