TooManyConcurrentRequests raised when bzr+ssh push is interrupted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Triaged
|
Medium
|
Unassigned |
Bug Description
Andrew Hunter reports:
Bzr does not handle a keyboard interupt (Ctl+c) nicely during a push. It
gives the following traceback:
bzr: ERROR: bzrlib.
'<bzrlib.
reached its concurrent request limit. Be sure to finish_writing and
finish_reading on the currently open request.
Traceback (most recent call last):
File "/opt/local/
line 817, in run_bzr_
return run_bzr(argv)
File "/opt/local/
line 779, in run_bzr
ret = run(*run_argv)
File "/opt/local/
line 477, in run_argv_aliases
return self.run(
File "/opt/local/
line 763, in run
revision_
File "/opt/local/
190, in clone_on_transport
revision_
File "/opt/local/
line 127, in read_locked
return unbound(self, *args, **kwargs)
File "/opt/local/
line 489, in clone
self.
File "/opt/local/
line 412, in copy_content_into
return InterRepository
File "/opt/local/
line 167, in write_locked
self.unlock()
File "/opt/local/
110, in unlock
self.
File "/opt/local/
line 475, in unlock
self.
File
"/opt/local/
294, in unlock
self.
File "/opt/local/
298, in unlock
self.confirm()
File "/opt/local/
386, in confirm
info = self.peek()
File "/opt/local/
409, in peek
info = self._read_
File "/opt/local/
399, in _read_info_file
return self._parse_
File
"/opt/local/
line 192, in get
return StringIO(
File
"/opt/local/
line 196, in get_bytes
request = self.get_
File "/opt/local/
line 412, in get_request
return SmartClientStre
File "/opt/local/
line 566, in __init__
raise errors.
TooManyConcurre
'<bzrlib.
reached its concurrent request limit. Be sure to finish_writing and
finish_reading on the currently open request.
bzr 0.90.0 on python 2.4.4.final.0 (darwin)
arguments: ['/opt/
'bzr+ssh://<email address hidden>
** please send this report to <email address hidden>
We're trying to unlock the remote repository, but the smart server medium is still in use by the interrupted operation.
I can see two options:
* unlock should drain out the medium, discarding the current response, before sending its unlock request
* delegate responsibility for releasing the lock to the server, when the medium is dropped -- but in general we have said we will allow clients to hold locks across connections.