Also, the initial report was "idle ssh transport". Monty's traceback is
certainly not 'idle' given that we are actively fetching content.
And while the transfer-of-content is roughly stateless, I'm not 100%
sure we want to default-reconnect SSH connections.
I suppose we could use a reasonable try-again-but-not-forever, or
try-once-but-fail-if-last-connect-failed. People with flaky connections
would get slow-but-useful connections. Restarting codehosting would
allow things to continue roughly interrupted, but the network going down
wouldn't cause us to spin indefinitely.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/2/2011 12:45 PM, Jelmer Vernooij wrote:
> ** Changed in: bzr Importance: High => Critical
>
> ** Changed in: bzr Assignee: (unassigned) => canonical-bazaar
> (canonical-bazaar)
>
Is this actually critical?
Also, the initial report was "idle ssh transport". Monty's traceback is
certainly not 'idle' given that we are actively fetching content.
And while the transfer-of-content is roughly stateless, I'm not 100%
sure we want to default-reconnect SSH connections.
I suppose we could use a reasonable try-again- but-not- forever, or but-fail- if-last- connect- failed. People with flaky connections
try-once-
would get slow-but-useful connections. Restarting codehosting would
allow things to continue roughly interrupted, but the network going down
wouldn't cause us to spin indefinitely.
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
8AXUACgkQJdeBCY SNAANUhQCgqCGM8 zIhGfqife6E2TIa LwQx GM6t7/uy+ SmXgQlXt
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk4
Nc4AnRq18lIiBiy
=8wVS
-----END PGP SIGNATURE-----