bzr pull bzr+ssh into a bound branch fails with TooManyConcurrentRequests

Note the situation here:

  * I've got a branch bound to bzr+ssh://server/foo
  * I'm trying to pull changes from a different branch on the same server: bzr+ssh://server/bar

bzr pull http://server/bzr worked fine (after making the directory visible through http), so it's not the fact that I'm pulling into a bound branch, it's the fact that I'm trying to access it over ssh that's the problem.

bzr pull bzr+ssh://server/bar works fine now when there are no more changes to pull.

The server is running bzr version 1.13.1 from jaunty.

I can reproduce this with bzr.dev. Glancing at the log file I think the problem is that bzr is attempting to do a get_stream and insert_stream over the one HPSS connection simultaneously.

Ideally this would happen entirely server-side, but failing that bzr ought to make a second connection in this case.

Thanks for the clear bug report.

On Mon, 2009-11-16 at 23:08 +0000, Andrew Bennetts wrote:
> I can reproduce this with bzr.dev. Glancing at the log file I think the
> problem is that bzr is attempting to do a get_stream and insert_stream
> over the one HPSS connection simultaneously.
>
> Ideally this would happen entirely server-side, but failing that bzr
> ought to make a second connection in this case.

Or multiplex at the logical layer. Specifically:
 - on HTTP we need a new connection, but HTTP can care for that
 - on streaming bzr we could conceptually coexist the two streams - they
are in opposite directions.

Might be a crack idea.

-Rob

This bug also affects qbzr (and therefore explorer) via the qconfig dialog.

1. browse a bound branch in bzr explorer
2. launch qconfig (via Settings>Configuration>User Configuration)
3. click "ok" in the qconfig dialog ==> CRASH!

Martitza: The bug you describe is a different bug to the original, so I have logged Bug #702543

Steps to reproduce together with full stack trace from current bzr.dev. I guess this might be mainly useful as a unit test case. Notice that thet error will leave a stale lock in place, which I'd consider another error. Imho all locks should be released using suitable 'finally' clauses. Or is the connection unusable after this error occurred?

$ bzr init -q trunk
$ echo one > trunk/foo
$ bzr add -q trunk/foo
$ bzr commit -q -m one trunk
$ bzr branch -q trunk branch
$ echo two > branch/foo
$ bzr commit -q -m two branch
$ bzr checkout bzr+ssh://localhost/${PWD}/trunk checkout
$ bzr pull -d checkout bzr+ssh://localhost/${PWD}/branch
bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://None@localhost/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.

Traceback (most recent call last):
  File "bzrlib/commands.py", line 918, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "bzrlib/commands.py", line 1118, in run_bzr
    ret = run(*run_argv)
  File "bzrlib/commands.py", line 676, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "bzrlib/commands.py", line 698, in run
    return self._operation.run_simple(*args, **kwargs)
  File "bzrlib/cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "bzrlib/cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "bzrlib/builtins.py", line 1080, in run
    show_base=show_base)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/workingtree.py", line 1013, in pull
    local=local)
  File "bzrlib/branch.py", line 1103, in pull
    possible_transports=possible_transports, *args, **kwargs)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/branch.py", line 3367, in pull
    run_hooks=False)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/remote.py", line 2992, in pull
    _override_hook_target=self, **kwargs)
  File "bzrlib/branch.py", line 1103, in pull
    possible_transports=possible_transports, *args, **kwargs)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/branch.py", line 3372, in pull
    merge_tags_to_master=not source_is_master)
  File "bzrlib/branch.py", line 3502, in _pull
    graph=graph)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/branch.py", line 3315, in _update_revisions
    self.fetch(stop_revision=stop_revision)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/branch.py", line 3292, in fetch
    fetch_spec=fetch_spec)
  File "bzrlib/remote.py", line 1660, in fetch
    find_ghosts=find_ghosts, fetch_spec=fetch_spec)
  File "bzrlib/decorators.py", line 217, in write_locked
    result = unbound(self, *args, **kwargs)
  File "bzrlib/vf_repository.py", line 2512, in fetch
    find_ghosts=...

The attached branch lp:~gagern/bzr/bug483661-pull-bound has a quick fix for this issue: it simply avoids reusing connections for the two branches involved. The test case is not containes in that branch. A better solution might be avoiding the concurrency or checking which transports allow concurrent requests, possibly reusing only those.