Re: [BUG]: Gnus randomly refuse to fetch and display articles

[Kevin Greiner <kevin.greiner@vignette.com>]

Xavier Maillard <zedek@gnu-rox.org> writes:

> On 13 oct 2004, Kevin Greiner wrote:
>
>> Xavier Maillard <zedek@gnu-rox.org> writes:
>> 
>> > On 11 oct 2004, Xavier Maillard wrote:
>> > 
>> > > Hello,
>> > > 
>> > > New problem I have since 2 or 3 days now.
>> > > 
>> > > Sometimes for an unknown reason, I get this backtrace when
>> > > trying to display an article:
>> > > 
>> > > ,----
>> > > > 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("\b
>> > > > =ƒ% gnus-async-wait-for-article(15716)
>> > > > gnus-async-request-fetched-article("nntp+gnu-rox.org:gnus.ding"
>> > > > 15716 #<buffer *Article*>)
>> > > > 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)
>> > > `----
>> > > 
>> > > 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 *** 
>> > `----
>> > 
>> > 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.
>
> Oh yes I see.
>
>> So, try replacing (nntp-accept-process-output proc) in
>> gnus-async-wait-for-article with (nntp-accept-process-output
>> (nntp-find-connection (current-buffer))).
>
> Hmm, looking at the function I see:
>
> (defun gnus-async-wait-for-article (article)
>   "Wait until ARTICLE is no longer the currently-being-fetched article."
>   (save-excursion
>     (gnus-async-set-buffer)
>     (let ((proc (nntp-find-connection (current-buffer)))
> 	  (nntp-server-buffer (current-buffer))
> 	  (nntp-have-messaged nil)
> 	  (tries 0))
>       (condition-case nil
> ...
>
> SHould I need to unbind proc ?

No.  It doesn't hurt to bind it but not use it.

Kevin