Re: maybe breakage with latest git-pull and http protocol

Junio C Hamano [off-list ref] writes:

merlyn@stonehenge.com (Randal L. Schwartz) writes:

quoted

OK, it happened this morning.  While syncing to update from
yesterday's version, I got:

Thanks.

quoted

    localhost:~/MIRROR/git-GIT % git-pull
    Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
    Getting alternates list
    got 4546738b58a0134eef154231b07d60fc174d56e3
    walk 4546738b58a0134eef154231b07d60fc174d56e3
    got d402d5566fdf226697a386dfb9858e5d954e9b91
    got 873d8e5652c06c3891278f33546c437efc209c2d
    walk d402d5566fdf226697a386dfb9858e5d954e9b91
    error: 
    Getting pack list
    got 0207ab18a3876249a928e7539d8f594a4f6921f1

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 see this line could emit an empty error message, if errorstr
is empty.

	if (request->curl_result != CURLE_OK && request->http_code != 416) {
		ret = error("%s", request->errorstr);
		release_request(request);
		return ret;
	}

So if that is the case maybe my previous speculation that we
sometimes forget to issue a necessary request was wrong.  We
asked for that object and got an error from cURL library...

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.

On Sat, 15 Oct 2005, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

merlyn@stonehenge.com (Randal L. Schwartz) writes:

quoted

OK, it happened this morning.  While syncing to update from
yesterday's version, I got:

Thanks.

quoted

    localhost:~/MIRROR/git-GIT % git-pull
    Fetching refs/heads/master from http://www.kernel.org/pub/scm/git/git.git using http
    Getting alternates list
    got 4546738b58a0134eef154231b07d60fc174d56e3
    walk 4546738b58a0134eef154231b07d60fc174d56e3
    got d402d5566fdf226697a386dfb9858e5d954e9b91
    got 873d8e5652c06c3891278f33546c437efc209c2d
    walk d402d5566fdf226697a386dfb9858e5d954e9b91
    error: 
    Getting pack list
    got 0207ab18a3876249a928e7539d8f594a4f6921f1

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 see this line could emit an empty error message, if errorstr
is empty.

	if (request->curl_result != CURLE_OK && request->http_code != 416) {
		ret = error("%s", request->errorstr);
		release_request(request);
		return ret;
	}

So if that is the case maybe my previous speculation that we
sometimes forget to issue a necessary request was wrong.  We
asked for that object and got an error from cURL library...

It looks like we didn't get an error from the cURL library, actually, or 
it would have printed something. My guess is that it is getting to the 
point about while the request is still in progress, but I'm not seeing how 
that could happen.

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.

I believe the code is doing that, but elsewhere.

	-Daniel
*This .sig left intentionally blank*

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.

On Sat, Oct 15, 2005 at 03:41:35PM -0400, Daniel Barkalow wrote:

quoted

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.

I believe the code is doing that, but elsewhere.

Er, never mind what I said in my previous message.  Daniel is correct,
process_curl_messages() will try the next altbase if a request 404s.

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