Sftp type error #49363

[John Arbash Meinel]

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
>> taking
>> 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.
> 
> Rob
> 

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'
--- bzrlib/tests/test_transport_implementations.py
+++ bzrlib/tests/test_transport_implementations.py
@@ -710,6 +710,8 @@
                         % (e.__class__.__name__, e))
         else:
             self.fail('Did not get the expected ConnectionError or
NoSuchFile.')
+        # 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,
which uses:

event = threading.Event()
ssh_server.start_server(event, server)
event.wait(5.0)
stop_event.wait(30.0)

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.
self.join(5.0)

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
server.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060612/878f404a/attachment.pgp