git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Hengeveld <nickh@reactrix.com>
To: Junio C Hamano <junkio@cox.net>
Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>,
	git@vger.kernel.org, Daniel Barkalow <barkalow@iabervon.org>
Subject: Re: maybe breakage with latest git-pull and http protocol
Date: Sat, 15 Oct 2005 14:21:54 -0700	[thread overview]
Message-ID: <20051015212154.GB5509@reactrix.com> (raw)
In-Reply-To: <7v1x2mpx6m.fsf@assigned-by-dhcp.cox.net>

On Sat, Oct 15, 2005 at 09:22:25AM -0700, Junio C Hamano wrote:

> More interesting is this "error:" without error message.
> "Getting pack list" is a signal that we fell back to
> fetch_pack(), so this is coming from fetch_object().

I've seen that happen before fetch_pack used the active queue; open object
requests in the active queue would not be processed while fetch_pack was
transferring the pack, and in some cases a server had timed out a connection
from one of these requests by the time the active queue started processing 
again.  I worked around this at one point by detecting an empty server
response and retrying the request.

Changing all requests to run through the active queue seemed to fix the
problem, but it's possible that something is still holding up processing
long enough to cause a server timeout.

> BTW, I do not think this is related to git.git repository
> problem, but I wonder why we do not do fetch_object() against
> each altbase in http-fetch.c::fetch(); nobody said you cannot
> borrow unpacked object from your neighbour.

It doesn't look like there are any alternates defined in the git.git
repository.  I've seen alternates used during testing when I deliberately
removed objects and packs from the primary repository.

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

  parent reply	other threads:[~2005-10-15 21:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-13  0:53 maybe breakage with latest git-pull and http protocol Randal L. Schwartz
2005-10-13  5:50 ` Junio C Hamano
2005-10-14 10:58 ` Randal L. Schwartz
2005-10-14 15:42   ` Junio C Hamano
2005-10-14 16:18     ` Randal L. Schwartz
2005-10-14 19:56       ` Daniel Barkalow
2005-10-15 13:03         ` Randal L. Schwartz
2005-10-15 16:04           ` Junio C Hamano
2005-10-15 16:22             ` Junio C Hamano
2005-10-15 19:41               ` Daniel Barkalow
2005-10-15 21:56                 ` Nick Hengeveld
2005-10-15 21:21               ` Nick Hengeveld [this message]
2005-10-15 16:37           ` Junio C Hamano
2005-10-15 17:13           ` Junio C Hamano
2005-10-15 21:57           ` Nick Hengeveld
2005-10-15 22:04             ` Randal L. Schwartz
2005-10-20 17:43 ` Nick Hengeveld

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=20051015212154.GB5509@reactrix.com \
    --to=nickh@reactrix.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=merlyn@stonehenge.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).