[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gump
Subject:    Re: Process management
From:       Stefan Bodewig <bodewig () apache ! org>
Date:       2005-04-27 9:34:27
Message-ID: m3pswga7h8.fsf () bodewig ! bost ! de
[Download RAW message or body]

On Wed, 27 Apr 2005, Leo Simons <mail@leosimons.com> wrote:
> On 27-04-2005 00:35, "Adam R. B. Jack" <ajack@apache.org> wrote:

>> Hence those lines of ugly code are not yet removable. Further, we
>> need to make Gump3 start to kill sub-processes after a timeout (say
>> on a spinning Ant build), or at least (1) not hang on them
>> indefinately (2) stop them burning CPU if spinning.
> 
> Question: does it matter if the processes are killed after one our
> or after four hours (the end of a run)?

As long as Gump proceeds with the next project it probably doesn't
matter too much.

> Question 2: do we actually get processes that die so badly they
> consume loads of CPU?

Yes, we had in the past.  The details are escaping me, but we did have
processes that ate all available CPU time for as long as you allowed
them to do.

> Thinking about this more, when those kinds of ugly errors do occur,
> they're indeed a problem with the project the command is associated
> with, and we should be sending them e-mail.

commons-net regularly hangs on Kaffe and works fine for any other VM,
so it isn't necessarily a problem of the project.

Quite a few projects run into Gump's timeout if Brutus looses the
network - or just if Sun's server is down since their <javadoc> uses
<link> to point to J2(S|E)E Javadocs.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]