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

Re: [leafnode-list] Request for comments: fetchnews posting and deleting behaviour

Stefan Wiens <s.wi@xxxxxxx> writes:

> > I'm fixing this for _ma8 by removing the delposted callee function and
> > callers. An article can be deleted if it has been successfully posted on
> > any server, that way, only articles that have been posted successfully
> > will ever be deleted. As a side effect, failed.postings can be removed.
> One disadvantage of this approach is that rejected articles will
> remain in out.going. Fetchnews will try to post them again and
> again. Because the article is visible in the local spool, users won't
> immediately notice what has happened.

True, so we should keep failed.postings and move *rejected* posts there,
while a killed fetchnews/server timeout should keep the article in
out.going, since it has not really be tried.

> My changes to avoid loss of articles were:
> a) make postarticles() return success only if each particular article
>    has either been posted or linked successfully, or is already
>    present upstream (which also leads to its deletion),

If it's already upstream, it may immediately be deleted.

> b) call delposted() only if at least one postarticles() was
>    successful.

Wrong approach. Don't EVER call delposted. postarticles must handle this
on its own. delposted is working around the problem and may fail
horribly when your clock skews. Read: the entire idea of deleting the
out.going is broken design.

> This will avoid unnecessary posting attempts. I've set up a cron job
> to get notified of stuck articles; maybe failed.postings could be made
> a read-only group, to enable users to check why their articles aren't
> distributed.

This would mean making major changes to leafnode, namely it would
locally post the article along with a problem report. This is not how
Usenet news works.

[per-server out.going directories]
> With a command line option to inhibit removal from out.going, a
> similar behaviour could be achieved, with less configuration effort.

No. postarticles itself must care for deleting from out.going, since
it's the only function that knows for sure if an article is to be
removed or not.

Matthias Andree

leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list