From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Patterson Subject: [PATCH] scripts: substitute: Avoid infinite looping when updating the substitute list Date: Sun, 5 Jul 2015 20:21:06 -0400 Message-ID: <5599C9F2.4080207@uwaterloo.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040001070802000000090404" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBuf2-0004oe-1U for guix-devel@gnu.org; Sun, 05 Jul 2015 20:53:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZBuex-0007AV-KI for guix-devel@gnu.org; Sun, 05 Jul 2015 20:53:27 -0400 Received: from mailservices.uwaterloo.ca ([129.97.128.141]:47007 helo=minos.uwaterloo.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZBuex-00079U-Ef for guix-devel@gnu.org; Sun, 05 Jul 2015 20:53:23 -0400 Received: from [10.13.0.184] ([69.58.102.156]) (authenticated bits=0) by minos.uwaterloo.ca (8.14.4/8.14.4) with ESMTP id t660K8o8004875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 5 Jul 2015 20:20:10 -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: guix-devel@gnu.org This is a multi-part message in MIME format. --------------040001070802000000090404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, 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. I also considered ensuring that a good response code was received, but the handler deals with error response codes as well, so it seemed superfluous. 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. Thanks, Andy --------------040001070802000000090404 Content-Type: text/x-patch; name="0001-scripts-substitute-Avoid-infinite-looping-when-updat.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-scripts-substitute-Avoid-infinite-looping-when-updat.pa"; filename*1="tch" >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 updating the substitute list * guix/scripts/substitute.scm (http-multiple-get): Make use of the current response before reconnecting. --- guix/scripts/substitute.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm index 8b4fa36..e767d0f 100755 --- a/guix/scripts/substitute.scm +++ b/guix/scripts/substitute.scm @@ -468,8 +468,9 @@ to read the response body. Return the list of results." ;; case we have to try again. Check whether that is the case. (match (assq 'connection (response-headers resp)) (('connection 'close) - (close-port p) - (connect requests result)) ;try again + (let ((first-result (proc head resp body))) + (close-port p) + (connect tail (cons first-result result)))) ;try again (_ (loop tail ;keep going (cons (proc head resp body) result))))))))))) -- 2.4.5 --------------040001070802000000090404--