Sftp type error #49363
John Arbash Meinel
john at arbash-meinel.com
Mon Jun 12 17:15:15 BST 2006
Robert Collins wrote:
> On Mon, 2006-06-12 at 10:28 -0500, John Arbash Meinel wrote:
>> It is already taking 5 seconds. It just is now showing that it is
>> 5 seconds, rather than saying 2ms and then pausing for 5s before going
>> to the next test.
> Hmm? the teardown occurs *before* the test is marked as finished, so
> unless the 5 second timeout occurs in a __del__ method it should always
> report accurately...
> Do you know where it is occuring ?
> Anyhow, if it is already occuring, +1.
Well, if you just do:
bzr selftest -v connection.*SFTP
you will see that it reports 'SKIP 50ms', and then hangs there for
another few seconds (5s seems about right to me).
=== modified file 'bzrlib/tests/test_transport_implementations.py'
@@ -710,6 +710,8 @@
% (e.__class__.__name__, e))
self.fail('Did not get the expected ConnectionError or
+ # Just make SFTP tests cleanup faster
+ t = self.get_transport()
If I just add the above change, then the tests take ~5ms. Without that
change, they timeout taking 5s.
I don't really want to add that line since it is a hack, and we still
have problems that if the test fails, it takes 5s to cleanup. But it
does solve the immediate problem.
At one point I thought the tearDown() method was wrong, since it is
calling TestCase.tearDown() before self._server.tearDown(), but swapping
those had no effect.
If you look at the SFTPServer code you have the '_run_server' function,
event = threading.Event()
We also have SingleListener.stop() which uses:
# use a timeout here, because if the test fails, the server thread may
# never notice the stop_event.
Anyway, because of the multiple threads going around, and the weird
callbacks, etc. It is difficult to figure out where the flow of control
is going. The best I can work out is that SingleListener is passed the
_run_server as the callback function, which passes in the stop_event,
which is supposed to be triggered by SingleListener.stop(). But only
after the new event.wait(5.0) has been triggered.
So what we end up with is a couple of intertwined locking events. The
SFTPServer has its own event that will wait 5s for a connection, and
then exit. But the SingleListener also passes in an event that the
SFTPServer will wait on for up to 30s.
I don't know why the SFTPServer creates its own event, rather than
re-using the stop_event that it is passed.
Maybe that is part of when we were having cleanup problems in the SFTP
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060612/878f404a/attachment.pgp
More information about the bazaar