Re: Temporary server failure causing articles to be read

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


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:

    -> 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

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.

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


Colin Watson                                  []

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

  Powered by Linux