|
From: Leif M. <le...@ta...> - 2002-10-10 03:50:01
|
Lars,
The features that you requested below are all things that you can
build into your
application. There is nothing there that should require any special code
on the Wrapper
level.
You can catch uncaught exceptions by extending the ThreadGroup class
and overriding
the uncaughtException(thread, throwable) method. You then launch the
threads of your
application within this thread group.
It would be possible to do this in the Wrapper by launching the
applications within a
custom WrapperThreadGroup. But I am wary of doing that as it would
likely cause problems
with some applications. A lot of server apps which are using the
Wrapper make heavy use
of thread groups. Most likely it would not cause any problems (??) But
I would not be able
to catch any exceptions from threads created by other thread groups, so
the feature would
not work consistently.
The second request about memory monitoring can be handled very
easily by your application.
(The best option would be to fix the leak :-) ) But to implement this.
Simply monitor the memory
using using the following:
Runtime r = Runtime.getRuntime();
if ( r.totalMemory() - r.freeMemory() > 128 * 1024 * 1024 )
{
WrapperManager.restart();
// Will not get here.
}
Just put that code in a daemon thread and let it run.
Cheers,
Leif
GMX wrote:
>Hi,
>
>I would like to ask if it is possible to add some more functionality to the
>wrapper code.
>
>First, the ability to detect certain exceptions and as a result restart the
>machine. Mainly I am thinking about a OutOfMemoryException, which can occur
>if a system runs for a long time and somehow the code does not clear out its
>resources. Or a slight memory leak, which of course should be fixed in the
>first place but with that extra functionality in the wrapper it would mean
>to have another countermeasure against dreadful bugs.
>
>Second, and this is along the same line, monitoring the memory usage. Say
>you have set the maximum memory to 128Mb, it would then be good to set some
>sort of threshold to monitor the garbage collection and its effectiveness.
>In other words, when the memory increases above a certain limit and then
>stays there for a given amount of time, then restart the app. This is for
>the same reasons as above. Usually the garbage collector thread should free
>enough resources ones they are filled up, but when buggy code keeps eating
>resources, the garbage collector can only free a small percentage each time,
>even when running full garbage collections. As an example the minimum used
>memory limit that triggers this watchdog could be set to 112Mb and the time
>limit to 15 mins. If the memory usage does not drop below 112Mb within 15
>mins from the time it got over that memory usage level, then restart the
>app.
>
>What I do not know without diving head on into the code is of this sort of
>thing is possible with the way wrapper is working and if that information
>can be reliably gathered using C or Java code.
>
>I hope I explained this thoroughly enough. Any help/hint/idea is highly
>appreciated. Keep up the good work!
>
>Kind regards,
>Lars
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>
|