From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58834 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: [BUG]: Gnus randomly refuse to fetch and display articles Date: Tue, 12 Oct 2004 22:54:32 -0400 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1097636122 25499 80.91.229.6 (13 Oct 2004 02:55:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 13 Oct 2004 02:55:22 +0000 (UTC) Original-X-From: ding-owner+M7372@lists.math.uh.edu Wed Oct 13 04:55:09 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CHZID-0002F7-00 for ; Wed, 13 Oct 2004 04:55:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1CHZHl-0007Bk-00; Tue, 12 Oct 2004 21:54:42 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CHZHh-0007Bf-00 for ding@lists.math.uh.edu; Tue, 12 Oct 2004 21:54:37 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CHZHg-0008Ok-5B for ding@lists.math.uh.edu; Tue, 12 Oct 2004 21:54:36 -0500 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id 998AF3A021F for ; Tue, 12 Oct 2004 21:54:35 -0500 (CDT) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1CHZHe-00037A-00 for ; Wed, 13 Oct 2004 04:54:34 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 67 Original-NNTP-Posting-Host: h-68-167-144-165.mclnva23.covad.net Original-X-Trace: quimby.gnus.org 1097636074 11975 68.167.144.165 (13 Oct 2004 02:54:34 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Wed, 13 Oct 2004 02:54:34 +0000 (UTC) User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt) Cancel-Lock: sha1:NCNXTIrVwbCkGERAraUkphm6NAs= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:58834 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58834 Xavier Maillard writes: > On 11 oct 2004, Xavier Maillard wrote: > >> Hello, >>=20 >> New problem I have since 2 or 3 days now. >>=20 >> Sometimes for an unknown reason, I get this backtrace when >> trying to display an article: >>=20 >> ,---- >> > Debugger entered--Lisp error: (error "Server closed >> > connection") signal(error ("Server closed connection")) >> > error("Server closed connection") apply(error "Server closed >> > connection") nntp-report("Server closed connection") >> > nntp-accept-process-output(nil) byte-code("=08 =3D=C2=83% >> > gnus-async-wait-for-article(15716) >> > gnus-async-request-fetched-article("nntp+gnu-rox.org:gnus.ding" >> > 15716 #) >> > gnus-request-article-this-buffer(15716 >> > "nntp+gnu-rox.org:gnus.ding") gnus-article-prepare(15716 nil) >> > gnus-summary-display-article(15716 nil) >> > gnus-summary-select-article(nil nil pseudo) >> > gnus-summary-scroll-up(1) >> > call-interactively(gnus-summary-scroll-up) >> `---- >>=20 >> It doesn't happen every time but in a random fashion. I can for >> example read 10 articles in a row and then, Gnus refuse to >> display one. Dunno what can cause this to happen since I have >> this behavior when plugged or not. > > Any taker ? > > I tried to (setq nntp-record... t) and switched to the > corresponding buffer but all I get is: > > ,---- > | 20041012T002908.472 gnu-rox.org *** CALLED nntp-report ***=20 > `---- > > This is kind of annoying since I don't really know what can block > this. > > Any help *grantly* appreciated. > > Hint: I just upgraded my local copy of Gnus from CVS and still > got this after having restarted Gnus. The problem is that some nntp servers close idle connections to conserve their resources while others punish a client that leaves idle connections open by ignoring future requests. The nntp backend handles both of these problems by wrapping the nntp command logic in the nntp-with-open-group form. Just guessing but I'd bet that the problem is that gnus-async-wait-for-article binds proc. The nntp-with-open-group recovers from a closed nntp connection by opening a new connection. The gnus-async-wait-for-article nevers sees that new connection because it binds proc before it enters its loop. So, try replacing (nntp-accept-process-output proc) in gnus-async-wait-for-article with (nntp-accept-process-output (nntp-find-connection (current-buffer))). Kevin