On 10/14/2011 2:32 PM, Jelmer Vernooij wrote:
> Public bug reported:
>
> The daily builds are occasionally getting a spurious test failure:
>
This had been happening on Babune, which caused me to introduce this
change:
6197 Patch Queue Manager 2011-10-06 [merge]
(jameinel) Allow for some tests to run slowly under load. (John
A Meinel)
=== modified file 'bzrlib/tests/test_server.py'
--- bzrlib/tests/test_server.py 2011-10-03 14:15:44 +0000
+++ bzrlib/tests/test_server.py 2011-10-05 15:01:54 +0000
@@ -616,7 +616,7 @@ return
class TestingSmartServer(TestingThreadingTCPServer,
server.SmartTCPServer):
So if they are still failing, that would indicate the single test is
taking more than 1 minute to complete.
Note that if this really is the failure, the connection retry code
that I wrote should also handle this by just retrying from the client
side.
Though in that traceback there isn't a ConnectionTimeout. Instead it
looks like one side just closes the connection.
Specifically, it looks like the client sends some data, and indicates
that the message is done. The server reads this information, but feels
there is more that needs to be said, and raises an exception, closing
the connection to the client.
Now, if the client is genuinely sending a malformed message, that is
how it is supposed to work.
If find it odd that the test highlighted here is also the one that was
failing because of timeouts, though.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/14/2011 2:32 PM, Jelmer Vernooij wrote:
> Public bug reported:
>
> The daily builds are occasionally getting a spurious test failure:
>
This had been happening on Babune, which caused me to introduce this
change:
6197 Patch Queue Manager 2011-10-06 [merge] tests/test_ server. py' tests/test_ server. py 2011-10-03 14:15:44 +0000 tests/test_ server. py 2011-10-05 15:01:54 +0000
return
(jameinel) Allow for some tests to run slowly under load. (John
A Meinel)
=== modified file 'bzrlib/
--- bzrlib/
+++ bzrlib/
@@ -616,7 +616,7 @@
- _DEFAULT_ TESTING_ CLIENT_ TIMEOUT = 4.0 _DEFAULT_ TESTING_ CLIENT_ TIMEOUT = 60.0
+
class TestingSmartSer ver(TestingThre adingTCPServer, SmartTCPServer) :
server.
So if they are still failing, that would indicate the single test is
taking more than 1 minute to complete.
Note that if this really is the failure, the connection retry code
that I wrote should also handle this by just retrying from the client
side.
Though in that traceback there isn't a ConnectionTimeout. Instead it
looks like one side just closes the connection.
Specifically, it looks like the client sends some data, and indicates
that the message is done. The server reads this information, but feels
there is more that needs to be said, and raises an exception, closing
the connection to the client.
Now, if the client is genuinely sending a malformed message, that is
how it is supposed to work.
If find it odd that the test highlighted here is also the one that was
failing because of timeouts, though.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk6 dXcIACgkQJdeBCY SNAAOqnwCfbWQEK oui8be0OgQdtris Fl8v GmFh7j8xm43F0p8 hh
oCUAoKgRrbywsXv
=062Z
-----END PGP SIGNATURE-----