interrupting a client waiting for a lock over bzr+ssh leaves process on server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
High
|
Martin Pool | ||
Launchpad itself |
Fix Released
|
High
|
Jonathan Lange |
Bug Description
This is a bit confusing. Here's how to reproduce:
1) lock a branch (i used "python2.4 -c 'from bzrlib import branch; branch.
2) attempt to push to the branch over bzr+ssh ("bzr push bzr+ssh:
3) break the lock (with "bzr break-lock /tmp/whatever", no bzr+ssh here)
4) attempt to push again. It still waits for a lock. Wtf??
I think what is happening here is that the 'bzr serve' process created in step 2 is still hanging around waiting for the lock that was created in step 1 to be released. Step 3 breaks this lock, allowing this 'bzr serve' process to grab the lock and cause confusion in step 4.
If I remember discussion correctly from somewhere, bzr probably isn't closing the ssh channel properly or something. Anyway, this bug creates very confusing situations, so it should be fixed sooner rather than later IMHO...
Changed in launchpad-bazaar: | |
status: | Confirmed → Fix Released |
I'm guessing the fix might be for the bzr serve process to notice when the client has exited after taking the lock, and go ahead and unlock itself.
I know we are trying hard for the smart protocol to be stateless, though. Which makes it difficult to have any sort of chat between the client and server, to let it know that the client is still around.
Another issue is having the bzr server say to the client "I'm waiting on the lock, I'll get back to you in a bit." I'm not sure this can be done if we expect each RPC to have a single Request => Response. Rather than a Request => Ongoing Response. Though if HTTP supports "Ongoing Response" then we could probably make use of it.
The *best* solution is to get more smarts in the protocol, so that we never actually have to request a lock be taken. If all actions are streamed and self-contained then the bzr process on the server will lock and unlock on its own, and not care if the client disconnects.