Re: Temporary server failure causing articles to be read

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Colin Watson wrote:
> On Wed, Mar 27, 2002 at 05:21:12PM +0000, Jonathan Larmour wrote:
> > 499 Try again later - remote server down?
> >
> > The issue is that when trn gets this, it treats it as a permanent, not
> > temporary failure. So e.g. reports "article is not available" and then
> > *proceeds to mark the article as read*! This is obviously not good for a
> > temporary problem as I will now never see the article.
> >
> > I'm happy to try and fix any code in trn (or nntpcache), but I need a few
> > pointers where to start, and/or if there is a better code for nntpcache to
> > return - I notice *9* is meant to be debug messages only.
> The relevant control flow is something like this:
>   do_newsgroup()
>     -> nntp_stat_id() (retrieve article by message-id)
>          -> nntp_command() (send NNTP command)
>          -> nntp_check() (check result of previous NNTP command)
>               will return 0 for 4xx and -1 for 5xx
> If nntp_check() and thus nntp_stat_id() returns -1, do_newsgroup() will
> clean up and leave the newsgroup. If it returns 0, do_newsgroup() will
> continue to try to open the article, and if it can't it assumes the
> article is missing and marks it read. This is generally correct - the
> standard 4xx codes you can get from trying to retrieve an article all
> either indicate "no such article" or "no such newsgroup". However, in
> your case I'm not sure that 5xx => leave newsgroup is great behaviour
> either.

Doesn't seem like it. Thanks for the background though, that helps.
> You probably want to edit ng.c, look down for nntp_stat_id(), and after
> the (art < 0) check add something that inspects the NNTP code at the
> start of ser_line and does 'goto reask_article' if it's 499.

Unfortunately it's likely that if the upstream server is down, then
reasking for it won't make any difference for maybe an hour.

> I'll leave it to wiser heads to decide whether nntpcache is doing the
> right thing.

It's possible that it's just a deficiency in RFC977 that it doesn't allow
temporary failures - unless there's a subsequent RFC which adds it?

Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[Index of Archives]     [Photo]     [Yosemite]     [Epson Inkjet]     [Mhonarc]     [Nntpcache]

  Powered by Linux