Transport connection caches must go.

Robert Collins robertc at robertcollins.net
Tue May 23 01:50:02 BST 2006


On Mon, 2006-05-22 at 19:43 -0500, John Arbash Meinel wrote:
> Robert Collins wrote:
> > On Mon, 2006-05-22 at 08:32 -0500, John Arbash Meinel wrote:
> >> Michael Ellerman wrote:
> > 
> > 
> >> That is the way the current code is. But both ftp and sftp cache their
> >> connections. It would seem reasonable that HTTP could do the same thing.
> > 
> > please no. The SFTP connection cache is an ongoing burden and I'm about
> > +5 for any patch that removes it with extreme prejuidice. 
> > 
> > There was a previous thread on this a few weeks back, but the title
> > wasn't changed unfortunately.
> > 
> > -Rob
> 
> What would you prefer? I think we should have some sort of keep-alive.
>
> One could argue for a single BzrDir connection. But I think it would be
> nice if doing "bzr branch sftp://foo/one sftp://foo/two" didn't require
> you to login twice. And remembering the connection at the Transport
> level seems the right place to do it.
> 
> Right now the sftp cache is just a weakref dictionary, so it should
> expire when nobody is using it anyway.

The intent of the cache is to avoid expensive operations like
connecting, or passphrase entry, occurring more than once. However, a
cache is not a guarantee of this. We need to structure our code such
that it can never require a new connection, and if we do that the cache
is no longer of benefit at all.

Having the cache makes tests more complex, has in fact caused bugs in
tests, and generally adds complexity thats IMO unneeded.

In the specific case case you mention, its possible that a cache is the
best way, but I'll think about this in more detail next week. 

Rob



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060523/e148d02e/attachment.pgp 


More information about the bazaar mailing list