From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>, Jeff King <peff@peff.net>,
git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: [PATCH 0/2] Retry attempts to acquire the packed-refs lock
Date: Fri, 1 May 2015 16:52:55 +0200 [thread overview]
Message-ID: <1430491977-25817-1-git-send-email-mhagger@alum.mit.edu> (raw)
At GitHub we were seeing occasional lock contention over packed-refs.
It wasn't very common, but when you have as much git traffic as we
have, anything that *can* happen *will* happen.
The problem is that Git only tries to acquire locks a single time. If
that attempt fails, the whole process fails. So, for example, if two
processes are trying to delete two different references, one of them
can fail due to inability to acquire the packed-refs lock, even though
it could have succeeded if it had just waited a moment.
This patch series adds a new function,
hold_lock_file_for_update_timeout(), which retries the lock
acquisition for a specified length of time. The retries necessarily
have to use polling, which it does using a quadratic backoff with a
random component. It might be a bit overengineered for this single
purpose, but I wanted it to be usable in other contexts without second
thoughts.
This patch series also changes lock_packed_refs() to call the new
function with a timeout of 1 second (by default; the timeout is
configurable) and adds some tests that the retry and timeout are
working.
It might be that there are other call sites that would benefit from
retrying lock acquisition (the index file?), but this patch series
only applies the new functionality to packed-refs.lock.
We have a patch similar to this one running on our servers at GitHub,
with no problems observed so far.
This series applies to master. It is also available from my GitHub
repository:
https://github.com/mhagger/git branch lockfile-retry
Michael Haggerty (2):
lockfile: allow file locking to be retried with a timeout
lock_packed_refs(): allow retries when acquiring the packed-refs lock
Documentation/config.txt | 6 ++++
lockfile.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++--
lockfile.h | 16 ++++++++--
refs.c | 12 +++++++-
t/t3210-pack-refs.sh | 17 +++++++++++
5 files changed, 125 insertions(+), 5 deletions(-)
--
2.1.4
next reply other threads:[~2015-05-01 14:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 14:52 Michael Haggerty [this message]
2015-05-01 14:52 ` [PATCH 1/2] lockfile: allow file locking to be retried with a timeout Michael Haggerty
2015-05-11 18:04 ` Junio C Hamano
2015-05-01 14:52 ` [PATCH 2/2] lock_packed_refs(): allow retries when acquiring the packed-refs lock Michael Haggerty
2015-05-01 16:13 ` Johannes Sixt
2015-05-02 3:47 ` Michael Haggerty
2015-05-02 21:43 ` Johannes Sixt
2015-05-11 9:31 ` Michael Haggerty
2015-05-01 17:51 ` Stefan Beller
2015-05-01 18:22 ` Jeff King
2015-05-02 5:19 ` Michael Haggerty
2015-05-04 17:31 ` Stefan Beller
2015-05-05 19:21 ` Jeff King
2015-05-11 10:26 ` Michael Haggerty
2015-05-11 16:49 ` Jeff King
2015-05-11 17:49 ` Stefan Beller
2015-05-11 17:50 ` Stefan Beller
2015-05-03 2:12 ` [PATCH 0/2] Retry attempts to acquire " Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430491977-25817-1-git-send-email-mhagger@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).