Code review comment for lp:~gz/bzr/transport_post_connect_hook

Revision history for this message
Martin Packman (gz) wrote :

Just having a hook turned out to be insufficient, and results in worse hangs than the old get_transport hack as can be seen from the nearly four hour babune runtime last night:

<http://babune.ladeuil.net:24842/job/selftest-subset-windows/11/>

The problem is that RemoteTransport classes don't use _set_connection and generally behave rather differently. Throwing in a hook point in __init__ when a new medium is built gets us to a leak-free 40 minute runtime:

<http://babune.ladeuil.net:24842/job/selftest-subset-windows/13/>

However the semantics are not quite correct there. Even if we don't have to worry about remote reconnections (do we?) the post_connect hook is happening before the real connection, and potentially twice in the RemoteHTTPTransport case. Combined with the existing confusion over how many times disconnect gets called, it suggests this hook probably isn't sane enough to be generally useful. We do want the leak problem fixed asap though, so if anyone has any clever ideas...

« Back to merge proposal