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

[Luis G. <lui...@sk...>]

Leif,
Ahh yes.. Cross platform unity is the issue at hand.  And as you said,
the ability to execute is exactly what I'm thinking of.

We already have notifications when there are additions to the
environment, but we actually don't allow the JVM to restart on all but
the JMS server.  We prefer at the moment, to analize the situation and
find the cause of jvm to fail.  So we set the max_failed_invocations =
=3D1.
So then the service terminates.  I should have included this in my
initial email.  It probably would have made more sense of my message
when I ask whether or not the wrapper service termination would be a
considered a service failure.

Thanks.

Luis


-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]=20
Sent: Thursday, November 06, 2003 2:29 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Wrapper notification...


Luis,
    I'll try to think of a clean way to add the support you are asking=20
for.  I am worried about
whether or not it will be possible in a reasonable cross platform way=20
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=20
called whenever your
application is first launched.  This method would first call=20
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=20
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=20
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=20
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=20
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=20
>environment, and our app does a lot of number crunching which requires=20
>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=20
customer running an
application that is distributed across about 20 systems.  A combination=20
of Windows,
and Solaris.  Each of these systems uses less than 128MB so it is a=20
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=20
>errors, where log4j dies with that jvm.
> =20
>
True, the out of memory errors are displayed at a much lower level so I=20
don't think that
log4j would be able to catch them.  (?)  Not sure about the case where=20
the stdout/err
PrintStreams have been replaced with user classes.

>As I read from the previous email, I'm guessing my option of the=20
>wrapper on filter.action=3Dshutdown, would not invoke the NT service=20
>recovery.  Is this correct or did I misread?
> =20
>
True, I have not used the NT service recovery feature personally, but I=20
doubt it would
work.   I imagine that it is only monitoring the service process.  When=20
that exits, it takes
some action.  In this case the Wrapper is the service process.  The JVM=20
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=20
>events.  But since the focus of the wrapper is running jvm as service=20
>and providing reliability, this should be limited to events that are=20
>not controllable within a JVM which usually turns out to be a JVM=20
>shutdown. This should be supported by allowing executing a system call,

>keeping the changes to the wrapper to a minimal.
> =20
>
Lets hear any more ideas and I'll give it some more thought as well.

Cheers,
Leif




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does
SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

_______________________________________________________
This message is for the named recipient's use only.  It may contain =
sensitive and private proprietary information.  No confidentiality is =
waived or lost by any incorrect transmission.  If you are not the =
intended recipient, please immediately delete it and all copies of it =
from your system, destroy any hard copies of it and notify the sender.  =
You must not, directly or indirectly, use, disclose, distribute, print, =
or copy any part of this message if you are not the intended recipient.  =
Sakonnet Technology, LLC and its subsidiaries reserve the right to =
monitor all e-mail communications through their networks. Any views =
expressed in this message are those of the individual sender, except =
where the message states otherwise and the sender is authorized to state =
them to be the views of any such entity.  Unless otherwise stated, any =
pricing information given in this message is indicative only, is subject =
to change and does not constitute an offer to deal at any price quoted. =
Any reference to the terms of executed transactions should be treated as =
preliminary only and subject to our formal written confirmation.=20