2006-12-14 09:16:44 |
Martin Pool |
bug |
|
|
added bug |
2006-12-14 09:27:30 |
Martin Pool |
description |
I'm not sure why this is happening, but I was using 'bzr push
bzr+ssh://' to push something today, and I found that bzr actually maed
4 connections to the remote server. (This server prints a message when you connect, and I see 4 of them).
It seems to just be a problem with bzr+ssh:// because if I use bzr push sftp:// to the same machine, it only connects one time.
Now, I realize that we have an "evil" connection cache in the sftp
implementation, but connecting 4 times to push seems a little bit bad. I
don't really want to implement a connection cache, but that is probably
the easiest way to fix this. Any thoughts?
John
=:-> |
I'm not sure why this is happening, but I was using 'bzr push
bzr+ssh://' to push something today, and I found that bzr actually maed
4 connections to the remote server. (This server prints a message when you connect, and I see 4 of them).
It seems to just be a problem with bzr+ssh:// because if I use bzr push sftp:// to the same machine, it only connects one time.
Now, I realize that we have an "evil" connection cache in the sftp
implementation, but connecting 4 times to push seems a little bit bad. I
don't really want to implement a connection cache, but that is probably
the easiest way to fix this. Any thoughts?
John
=:-> |
|
2006-12-14 09:37:19 |
Martin Pool |
bzr: importance |
Undecided |
Medium |
|
2006-12-14 09:37:19 |
Martin Pool |
bzr: statusexplanation |
|
|
|
2007-05-01 21:46:26 |
John A Meinel |
bzr: status |
Unconfirmed |
Confirmed |
|
2007-05-01 21:46:26 |
John A Meinel |
bzr: importance |
Medium |
High |
|
2007-05-01 21:46:26 |
John A Meinel |
bzr: statusexplanation |
|
see also bug 86392
I tried this today, and by hiding my ssh key, I saw it connect 3 times. So we are doing slightly better as of 0.16 (RemoteTransport *does* pass around the reference)
I think this is because we are first using "to_transport = transport.get_transport(location)"
And from there we are trying to determine if the target exists or not (using BzrDir.open_from_transport(), etc)
Which is good so far.
But then bzrdir.clone() only takes a URL, not a Transport, so the transport cannot be re-used.
That accounts for 2 connections, I'm not sure how we get the 3rd.
Actually, it is probably because RemoteSSHTransport isn't properly cloning. (For one thing its __init__ doesn't have a clone_from. Second, the default RemoteTransport.clone() returns a RemoteTransport, rather than self.__class__()
|
|
2007-05-01 22:09:32 |
John A Meinel |
bzr: status |
Confirmed |
In Progress |
|
2007-05-01 22:09:32 |
John A Meinel |
bzr: assignee |
|
jameinel |
|
2007-05-01 22:09:32 |
John A Meinel |
bzr: statusexplanation |
see also bug 86392
I tried this today, and by hiding my ssh key, I saw it connect 3 times. So we are doing slightly better as of 0.16 (RemoteTransport *does* pass around the reference)
I think this is because we are first using "to_transport = transport.get_transport(location)"
And from there we are trying to determine if the target exists or not (using BzrDir.open_from_transport(), etc)
Which is good so far.
But then bzrdir.clone() only takes a URL, not a Transport, so the transport cannot be re-used.
That accounts for 2 connections, I'm not sure how we get the 3rd.
Actually, it is probably because RemoteSSHTransport isn't properly cloning. (For one thing its __init__ doesn't have a clone_from. Second, the default RemoteTransport.clone() returns a RemoteTransport, rather than self.__class__()
|
|
|
2007-05-01 22:54:06 |
Robert Collins |
bzr: importance |
High |
Critical |
|
2007-05-01 22:59:53 |
John A Meinel |
bzr: status |
In Progress |
Fix Committed |
|
2007-05-01 22:59:53 |
John A Meinel |
bzr: statusexplanation |
|
Fix available in the associated branch. |
|
2007-05-01 23:14:59 |
John A Meinel |
bzr: statusexplanation |
Fix available in the associated branch. |
|
|
2007-05-03 19:27:00 |
John A Meinel |
bzr: status |
Fix Committed |
Fix Released |
|
2007-05-03 19:27:00 |
John A Meinel |
bzr: statusexplanation |
|
This has been merged into bzr.dev 2479. I don't know if it will be in 0.16 or 0.17, but it *will* be in one of them. |
|