Merge lp:~parthm/bzr/250451-better-url-for-break-lock into lp:bzr
| Status: | Merged |
|---|---|
| Approved by: | Parth Malwankar on 2010-06-17 |
| Approved revision: | 5293 |
| Merged at revision: | 5303 |
| Proposed branch: | lp:~parthm/bzr/250451-better-url-for-break-lock |
| Merge into: | lp:bzr |
| Diff against target: |
214 lines (+66/-52) 5 files modified
NEWS (+5/-0) bzrlib/errors.py (+0/-2) bzrlib/lockdir.py (+32/-24) bzrlib/remote.py (+10/-3) bzrlib/tests/test_lockdir.py (+19/-23) |
| To merge this branch: | bzr merge lp:~parthm/bzr/250451-better-url-for-break-lock |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Vincent Ladeuil | 2010-06-09 | Needs Fixing on 2010-06-15 | |
| Martin Packman (community) | Needs Fixing on 2010-06-10 | ||
|
Review via email:
|
|||
Commit Message
Lock URL shown in case of failure to acquire lock (for smart server access) is now valid. Default timeout for lock contention is now 30s.
Description of the Change
=== Fixes Bug #250451 ===
This patch gives a more accurate url in case where bzr fails to obtain lock from smart server.
In the current implementation, the server passes details such as lock_url (inaccurate), user, time_ago, pid to client. These are displayed in bzrlib.
This patch, avoids displaying the inaccurate lock_url in the wait_lock. If the wait_fails, bzr raises a LockContention error in bzrlib.
Does this approach look reasonable? Any other areas of code that I should check? I would appreciate any pointers on what would be a good place to put tests for this.
One thing remaining would be to handle ^C in bzrlib.
Running the test locally, following is the interaction:
=======
[foo]% bzr push bzr+ssh:
Unable to obtain lock held by Parth Malwankar <email address hidden> at parthm-laptop [process #9606], acquired 7 hours, 52 minutes ago.
Will continue to try until 22:40:59, unless you press Ctrl-C.
See "bzr help break-lock" for more.
bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh:
[foo]%
Interacting with launchpad (which is running the un-patched server):
=======
[trunk]% bzr push lp:~parthm/+junk/lock-test
Unable to obtain lock lp-69989648:
held by <email address hidden> on host crowberry [process #26780]
locked 12 hours, 3 minutes ago
Will continue to try until 18:03:34, unless you press Ctrl-C.
See "bzr help break-lock" for more.
bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh:
[trunk]%
Current interaction (without patch)
=======
[trunk]% bzr push lp:~parthm/+junk/lock-test
Unable to obtain lock lp-69989648:
held by <email address hidden> on host crowberry [process #26780]
locked 12 hours, 2 minutes ago
Will continue to try until 18:03:15, unless you press Ctrl-C.
See "bzr help break-lock" for more.
bzr: ERROR: Could not acquire lock "(remote lock)":
| Parth Malwankar (parthm) wrote : | # |
Some discussion on ^C and timeout:
https:/
| Parth Malwankar (parthm) wrote : | # |
> + e.msg = self.repository
>
> That doesn't do what you want it too. Use `.split(".bzr")[0]` instead.
Wow. That was stupid :P Fixed.
> Would also prefer a less hacky change to the LockContention instance, there's
> a todo note on the class related to this.
Agreed. I have added a comment indicating that the lock_url is not know to
the server so the initial LockContention exception doesn't have this
info. A new LockContention is now raised and we avoid directly modifying
instance variables of the old exception.
This update also fixes tests and also add a (timeout > 0) check before
showing "Will continue to try .." message.
Thanks for the review.
This is what the current interaction looks like:
[foo]% bzr push bzr+ssh:
parthm@localhost's password:
Unable to obtain lock held by Parth Malwankar <email address hidden>
at parthm-laptop [process #9606], acquired 46 hours, 42 minutes ago.
See "bzr help break-lock" for more.
bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh:
[foo]%
[foo]% bzr push bzr://localhost
bzr: ERROR: Could not acquire lock "(remote lock)": bzr://localhost/
[foo]%
| Parth Malwankar (parthm) wrote : | # |
Some further improvements to this patch:
- As local lock urls are valid, these are displayed immediately. This way, even if the user chooses to ^C before the timeout, she would still know the url even though ^C keeps LockContention error from being raised.
- Default timeout for lock contention retry reduced from 300s to 10s (discussion: comments 3 and 4 for bug #592148)
- Cleanup display of local lock url. i.e.
Display:
bzr: ERROR: Could not acquire lock "(local)": file://
instead of:
LockContention: Could not acquire lock "LockDir(
Local error is now:
===================
[foo]% bzr push ../trunk
Unable to obtain lock file://
held by Parth Malwankar <email address hidden>
at parthm-laptop [process #9606], acquired 91 hours, 3 minutes ago.
Will continue to try until 09:51:21, unless you press Ctrl-C.
See "bzr help break-lock" for more.
bzr: ERROR: Could not acquire lock "(local)": file://
Remote error is:
===================
[foo]% bzr push bzr+ssh:
Unable to obtain lock held by Parth Malwankar <email address hidden>
at parthm-laptop [process #9606], acquired 91 hours, 22 minutes ago.
See "bzr help break-lock" for more.
bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh:
[foo]%
| Parth Malwankar (parthm) wrote : | # |
Timeout updated to 30s based on discussion on bug #592148.
| Vincent Ladeuil (vila) wrote : | # |
Excellent !
One nit though so my vote is really Tweak (needs fixing but Approve if addressed and doesn't need another review):
66 + if lock_url.
67 + lock_url = lock_url.
96 + raise LockContention(
is a bit ugly, there should be a way to not add this '\n' instead so you don't have to remove it later. This '\n' is not part of the url anyway.
Not a big deal but I find it harder to read.
| Vincent Ladeuil (vila) wrote : | # |
Hmm, just re-read the bug comments, make sure you have agreement from John and Robert about the timeout value 30 or 5.
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent Ladeuil wrote:
> Hmm, just re-read the bug comments, make sure you have agreement from John and Robert about the timeout value 30 or 5.
So I wrote a fairly trivial plugin to time how much time is spent in
'save_pack_names'. It is available here:
lp:~jameinel/+junk/bzr_lock_test
(install as 'lock_test'). This is what I got:
local
$ bzr lock-test foo --count=100
commit: 100 0.033s avg, 0.203s max
save: 100 0.017s avg, 0.090s max
LAN sftp
$ bzr lock-test sftp://
commit: 100 0.537s avg, 4.100s max
save: 100 0.149s avg, 0.812s max
LAN smart VFS
$ bzr lock-test bzr+ssh:
commit: 100 0.410s avg, 3.203s max
save: 100 0.213s avg, 1.740s max
WAN sftp (my house in Chicago to chinstrap in London)
$ bzr lock-test sftp://
commit: 100 15.635s avg, 89.538s max
save: 100 5.965s avg, 29.668s max
WAN + smart VFS
$ bzr lock-test bzr+ssh:
commit: 100 7.683s avg, 104.901s max
save: 100 4.407s avg, 66.544s max
This code is testing VFS operations, rather than 'insert_stream()'
(mostly because I can't isolate the _save_pack_names time, and it should
be equivalent to 'local' time).
Note that 'commit' == 'commit_
autopack, but 'save' is just the _save_pack_names() time. Which includes
a write-lock, reading the remote pack-names, writing a new one, and
unlocking.
Note that it can take up to *30s* just to do that via sftp, and even 66s
w/ VFS.
The averages are in the ~5s range. So I think 10s is possibly ok, 1min
would be being generous (but still possible that 2 people could push to
different branches in a shared repository and have it fail when it could
have succeeded.)
I'm willing to say that the peaks are noise, but I still think a minimum
of 10s, and 30s is probably a decent safety margin. (And yes, if we
always used RPC, then probably <5s could be ok.)
I would be interested to see what people in AU see.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkw
pPgAoMgPoonzfnZ
=ShnQ
-----END PGP SIGNATURE-----
| Parth Malwankar (parthm) wrote : | # |
> Excellent !
>
> One nit though so my vote is really Tweak (needs fixing but Approve if
> addressed and doesn't need another review):
>
> 66 + if lock_url.
> 67 + lock_url = lock_url.
>
> 96 + raise LockContention(
>
> is a bit ugly, there should be a way to not add this '\n' instead so you don't
> have to remove it later. This '\n' is not part of the url anyway.
>
Yes. That was a little ugly. I was not too happy with it myself.
I had set it up that way to allow a line-break in case the url is printed. I have removed that now and rely on the terminal to wrap the text.
> Not a big deal but I find it harder to read.
| Parth Malwankar (parthm) wrote : | # |
> Hmm, just re-read the bug comments, make sure you have agreement from John and
> Robert about the timeout value 30 or 5.
John has posted his detailed comment and I synced up with Robert on IRC. Robert was ok with both 10 and 30, so I am keeping this the timeout as 30. As mentioned by John, that seems to have a decent margin.
| Parth Malwankar (parthm) wrote : | # |
sent to pqm by email

+ e.msg = self.repository .base.rstrip( '.bzr/' )
That doesn't do what you want it too. Use `.split(".bzr")[0]` instead.
Would also prefer a less hacky change to the LockContention instance, there's a todo note on the class related to this.