From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 1/2] upload-pack: send keepalive packets during pack computation
Date: Sun, 8 Sep 2013 05:01:31 -0400 [thread overview]
Message-ID: <20130908090131.GA17060@sigill.intra.peff.net> (raw)
In-Reply-To: <20130908085915.GA4097@sigill.intra.peff.net>
Whenn upload-pack has started pack-objects, there may be a
quiet period while pack-objects prepares the pack (i.e.,
counting objects and delta compression). Normally we would
see (and send to the client) progress information, but if
"--quiet" is in effect, pack-objects will produce nothing at
all until the pack data is ready. On a large repository,
this can take tens of seconds (or even minutes if the system
is loaded or the repository is badly packed). Clients or
intermediate proxies can sometimes give up in this
situation, assuming that the server or connection has hung.
This patch introduces a "keepalive" option; if upload-pack
sees no data from pack-objects for a certain number of
seconds, it will send an empty sideband data packet to let
the other side know that we are still working on it.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/config.txt | 11 +++++++++++
upload-pack.c | 25 ++++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..5d748f7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2216,6 +2216,17 @@ uploadpack.allowtipsha1inwant::
of a hidden ref (by default, such a request is rejected).
see also `uploadpack.hiderefs`.
+uploadpack.keepalive::
+ When `upload-pack` has started `pack-objects`, there may be a
+ quiet period while `pack-objects` prepares the pack. Normally
+ it would output progress information, but if `--quiet` was used
+ for the fetch, `pack-objects` will output nothing at all until
+ the pack data begins. Some clients and networks may consider
+ the server to be hung and give up. Setting this option instructs
+ `upload-pack` to send an empty keepalive packet every
+ `uploadpack.keepalive` seconds. Setting this option to 0
+ disables keepalive packets entirely. The default is 0.
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
diff --git a/upload-pack.c b/upload-pack.c
index 127e59a..c3e4a20 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -40,6 +40,7 @@ static unsigned int timeout;
static struct object_array want_obj;
static struct object_array extra_edge_obj;
static unsigned int timeout;
+static int keepalive = -1;
/* 0 for no sideband,
* otherwise maximum packet size (up to 65520 bytes).
*/
@@ -200,6 +201,7 @@ static void create_pack_file(void)
while (1) {
struct pollfd pfd[2];
int pe, pu, pollsize;
+ int ret;
reset_timeout();
@@ -222,7 +224,8 @@ static void create_pack_file(void)
if (!pollsize)
break;
- if (poll(pfd, pollsize, -1) < 0) {
+ ret = poll(pfd, pollsize, 1000 * keepalive);
+ if (ret < 0) {
if (errno != EINTR) {
error("poll failed, resuming: %s",
strerror(errno));
@@ -284,6 +287,21 @@ static void create_pack_file(void)
if (sz < 0)
goto fail;
}
+
+ /*
+ * We hit the keepalive timeout without saying anything; send
+ * an empty message on the data sideband just to let the other
+ * side know we're still working on it, but don't have any data
+ * yet.
+ *
+ * If we don't have a sideband channel, there's no room in the
+ * protocol to say anything, so those clients are just out of
+ * luck.
+ */
+ if (!ret && use_sideband) {
+ static const char buf[] = "0005\1";
+ write_or_die(1, buf, 5);
+ }
}
if (finish_command(&pack_objects)) {
@@ -785,6 +803,11 @@ static int upload_pack_config(const char *var, const char *value, void *unused)
{
if (!strcmp("uploadpack.allowtipsha1inwant", var))
allow_tip_sha1_in_want = git_config_bool(var, value);
+ else if (!strcmp("uploadpack.keepalive", var)) {
+ keepalive = git_config_int(var, value);
+ if (!keepalive)
+ keepalive = -1;
+ }
return parse_hide_refs_config(var, value, "uploadpack");
}
--
1.8.4.2.g87d4a77
next prev parent reply other threads:[~2013-09-08 9:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-08 8:59 [PATCH 0/2] upload-pack keepalive Jeff King
2013-09-08 9:01 ` Jeff King [this message]
2013-09-09 7:45 ` [PATCH 1/2] upload-pack: send keepalive packets during pack computation Eric Sunshine
2013-09-08 9:02 ` [PATCH 2/2] upload-pack: bump keepalive default to 5 seconds Jeff King
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=20130908090131.GA17060@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
/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).