[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