[Buildbot-commits] buildbot NEWS,1.34,1.35

Brian Warner warner at users.sourceforge.net
Sat Dec 11 20:59:08 UTC 2004


Update of /cvsroot/buildbot/buildbot
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24541

Modified Files:
	NEWS 
Log Message:
bring it up to date


Index: NEWS
===================================================================
RCS file: /cvsroot/buildbot/buildbot/NEWS,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -d -r1.34 -r1.35
--- NEWS	6 Dec 2004 08:09:30 -0000	1.34
+++ NEWS	11 Dec 2004 20:59:05 -0000	1.35
@@ -12,7 +12,9 @@
 is added to a pseudo-logfile for the step that was stopped, but if you only
 look at the top-level status it appears that the build failed on its own).
 
-Builds are also halted if the connection to the buildmaster is lost.
+Builds are also halted if the connection to the buildslave is lost. On the
+slave side, any active commands are halted if the connection to the
+buildmaster is lost.
 
 ** minor new features
 
@@ -33,9 +35,25 @@
 happen when the slave is sending large logfiles over a slow link, while using
 short keepalive timeouts. The buildmaster has been fixed to allow the second
 connection attempt to take precedence over the first, so that the older
-connection is jettisoned to make way for the newer one. This is half of the
-fix, the other will involve fixing the slave to avoid the double-connect
-situation in the first place.
+connection is jettisoned to make way for the newer one.
+
+In addition, the buildslave has been fixed to be less twitchy about timeouts.
+There are now two parameters: keepaliveInterval (which is controlled by the
+mktap 'keepalive' argument), and keepaliveTimeout (which requires editing the
+.py source to change from the default of 30 seconds). The slave expects to
+see *something* from the master at least once every keepaliveInterval
+seconds, and will try to provoke a response (by sending a keepalive request)
+'keepaliveTimeout' seconds before the end of this interval just in case there
+was no regular traffic. Any kind of traffic will qualify, including
+acknowledgements of normal build-status updates.
+
+The net result is that, as long as any given PB message can be sent over the
+wire in less than 'keepaliveTimeout' seconds, the slave should not mistakenly
+disconnect because of a timeout. There will be traffic on the wire at least
+every 'keepaliveInterval' seconds, which is what you want to pay attention to
+if you're trying to keep an intervening NAT box from dropping what it thinks
+is an abandoned connection. A quiet loss of connection will be detected
+within 'keepaliveInterval' seconds.
 
 *** Large Logfiles
 





More information about the Commits mailing list