massifor / distcc

Automatically exported from code.google.com/p/distcc
GNU General Public License v2.0
0 stars 0 forks source link

distcc should not automatically put a host into backoff state when it fails to compile #74

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
When distcc attempts to distribute an operation to some host, and the operation 
fails, it automatically puts that host into backoff state, preventing further 
use of this host for some time.

This is wrong. It would make more sense if it only put the host into backoff 
state if, after the failure, the local execution of the operation succeeds.

To illustrate how this is a problem:
When configuring my program with CMake, some tests are done, some of which 
fail, expectedly so (e.g. a check for some include file, which turns out to be 
missing), and this is not a problem in any way. However, distcc attempts to 
distribute compiling this test; that obviously fails. But then distcc puts the 
host into backoff mode, so it isn't used for some time, even though it's online 
and works.

I should note that in this case, the host itself was not involved in any way; 
the "distributed" operation failed at preprocessing state, which was done 
locally, and still, the host was put into backoff state.

Original issue reported on code.google.com by ambr...@gmail.com on 14 Nov 2010 at 7:10

GoogleCodeExporter commented 9 years ago
Another sorta related issue is that, if I read the sources correctly, distcc 
does puts hosts on backoff (ban of 60 seconds) if the remote host is busy with 
other compiles. If the remote host is busy with a compile it should be ignored 
for at most a few seconds, not a minute.  

I think another huge case (I mean this makes our builds take minutes longer 
when it happens, often due to users installing an anti-virus) is that if a host 
is taking too long to compile, and you only have one source active, it should 
try in parallel compiling it on another host at the same time.  If the other 
host wins, then the host that is taking too long should definitely be put on 
backoff.

Original comment by thehes...@gmail.com on 7 Sep 2011 at 8:40

GoogleCodeExporter commented 9 years ago
Hi, this patch should fix it.
It returns the host from backoff state, if local compilation returned the same 
result as remote one.

Original comment by Ktoni...@gmail.com on 10 Feb 2012 at 5:08

Attachments:

GoogleCodeExporter commented 9 years ago
Note also Issue 103 ... The backoff time can now be adjusted or the backoff 
behavior can be disabled altogether via the env var DISTCC_BACKOFF_PERIOD (as 
of SVN r761).

Original comment by kamal@whence.com on 4 Apr 2012 at 8:55

GoogleCodeExporter commented 9 years ago
Is anything wrong with my patch? Will it be merged?

Original comment by Ktoni...@gmail.com on 13 May 2012 at 5:32

GoogleCodeExporter commented 9 years ago
The patch looks good to me.  Applied in svn revision 772.

Original comment by fer...@google.com on 16 May 2012 at 5:45