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

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

[Xavier Maillard]

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.

Regards
-- 
Xavier MAILLARD (GnuPG: 1024D/1E028EA5)
EmacsOS user (http://emacsfr.org)
APRIL (http://www.april.org)

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

[Xavier Maillard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1718 bytes --]

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.

Thank you.
-- 
.o.                     | zedek (at) gnu-rox.org
..o Hacker Wonderland   | 
ooo                     | 

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

[Kevin Greiner]

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.

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

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

[Xavier Maillard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

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:


[-- Attachment #2: Type: application/emacs-lisp, Size: 334 bytes --]

[-- Attachment #3: Type: text/plain, Size: 97 bytes --]


SHould I need to unbind proc ?

Regards and thank you for your answer.
-- 
 In Gruuik we trust

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

[Kevin Greiner]

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

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

[Xavier Maillard]

On 13 oct 2004, Kevin Greiner wrote:

> > > So, try replacing (nntp-accept-process-output proc) in
> > > gnus-async-wait-for-article with
> > > (nntp-accept-process-output (nntp-find-connection
> > > (current-buffer))).

> > [ ... ]

> > SHould I need to unbind proc ?
> 
> No.  It doesn't hurt to bind it but not use it.

Well I tried your solution but it did not fix anything.

But I have remarked that, the error was not so random that it
seems to. In general, if for a reason or another, gnus refuses to
fetch and to display an article, whatever I could do (ie. exiting
the summary and entering again), gnus was refusing to display it
when trying again in the _same_ session. When quitting Gnus and
launching it again, I can view the article.

I have no clue of what can be done. All I can tell is that
appeared one week ago. Neither did I change my NNTP server nor
changed its configuration. I really don't see what can happen
here.

Regards.
-- 
Xavier Maillard, zedek@gnu-rox.org

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

[Xavier Maillard]

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

Problem is still present and it is really becoming annoying since it occurs more
and more frequently now (33% of the time).

I have remarked, that it also occurs for article cached and/or downloaded (using
the agent). I also remarked that if an article fails to display and I sqwitch to
another that also fails at this, then, going back to the first one displays it
correctly.

So, to be brief, here is how I finally can display an article:

1. RET or PSACE on an article (call it X) => FAILED
2. Same on a new article, say Y => FAILED
3. Go back to article X then RET or SPACE on it => SUCCESS 

?? What the hell is wrong ?

Thank you.

[SOLVED] (was: [BUG]: Gnus randomly refuse to fetch and display articles)

[Xavier Maillard]

Just a quick message to say that the problem is not occuring
anymore since I left leafnode and went back to INN.

It seems something was going wrong either with my old NNTP setup
--ie. using leafnode, or due to HDD performance (I tried to
delete the whole leafnode news directory and it took almost one
hour to do so).

Regards.
-- 
.o.   Xavier Maillard            Tel: +33 6 68 04 64 37
..o  
ooo