From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] scripts: substitute: Avoid infinite looping when updating the substitute list Date: Tue, 07 Jul 2015 01:08:28 +0200 Message-ID: <873810q3yr.fsf@gnu.org> References: <5599C9F2.4080207@uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCFV5-0003Eg-Vb for guix-devel@gnu.org; Mon, 06 Jul 2015 19:08:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCFV2-00046C-Kf for guix-devel@gnu.org; Mon, 06 Jul 2015 19:08:35 -0400 In-Reply-To: <5599C9F2.4080207@uwaterloo.ca> (Andy Patterson's message of "Sun, 5 Jul 2015 20:21:06 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andy Patterson Cc: guix-devel@gnu.org Hi, Andy Patterson skribis: > I was having trouble using substitutes, so I decided to investigate it. > I found out that when retrieving the batch of .narinfo files from the > server, my connection was always being closed after the first response. > Therefore, I would always be reconnecting to the server with every > request in the batch still to process, and this reconnecting would be > repeated infinitely, or at least until my Internet went down. Based on > the documentation for the "connection: close" header, I think that this > first response should be complete, so we can use it. Maybe I'm wrong; > I'm not totally familiar with how http works. Indeed, reads: The "close" connection option is defined for a sender to signal that this connection will be closed after completion of the response. > This patch will make use of the last response from the server, before > reconnecting to try the next one. With it I was able to successfully > build and run links. > > Let me know if my understanding is off, or if there's a better approach. I think you found a genuine bug and provided the right patch! Did you observe the problem when connecting to hydra.gnu.org, or was it another server? Did you have a way to reproduce it? (In my experience Nginx at hydra.gnu.org closes the connection after ~100 responses, so even if the last response is not consumed directly, that=E2=80=99s OK.) > From 633c491e2dad4c3a70eb045177c17bd2552d63f3 Mon Sep 17 00:00:00 2001 > From: Andy Patterson > Date: Sun, 5 Jul 2015 19:34:05 -0400 > Subject: [PATCH] scripts: substitute: Avoid infinite looping when updatin= g the > substitute list > > * guix/scripts/substitute.scm (http-multiple-get): Make use of the current > response before reconnecting. I=E2=80=99ve committed a slightly edited version of the patch where I facto= rized the call to PROC and changed the commit message to describe the changes at the source code level, in GNU change log style. (I hope this is fine with you.) Thank you! Ludo=E2=80=99.