Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!viusys!alembic!csu
From: csu@alembic.acs.com (Dave Mack)
Newsgroups: news.software.b
Subject: C News batcher goes insane - film at eleven
Message-ID: <1991Jun26.035746.14008@alembic.acs.com>
Date: 26 Jun 91 03:57:46 GMT
Organization: Alembic Computer Services, McLean VA
Lines: 37

Twice now, I've run into a situation where the C News batcher
manages to produce news batches containing no news. 

This is caused by an interaction between batchparms, expire,
the togo lists and the frequency of news transfer. If a site
calls relatively infrequently to get its news (or is down for
several days), and the batching site expires news fairly quickly,
it is relatively easy to get into a situation where the articles
referenced in the togo lists have expired before they are batched.
This is particularly easy with the default batch size of 20.
The batcher, as a result, produces batches containing nothing
but a "#! cunbatch" line followed by four garbage characters.

When the receiving site finally calls for its news, relaynews
faithfully delivers these junk batches ("inbound news garbled"
on the receiving end.) sendbatches, the next time it's called,
assembles another 20 (+/-) batches of articles which have expired.
By the time the calling site has called back for these, even more
articles have expired, and the cycle continues - for two weeks in
the most recent case.

In order to clear this, I either up the batch size and force
a more frequent poll from the calling site, or to nuke the togo
lists and start over.

The problem goes unreported because the batcher doesn't produce any
error output if the files in the togo list aren't there, unless
debugging (batcher -x) is turned on, which it normally isn't.

After staring at the code in sendbatches and batcher for a while,
I suspect that a major rewrite of sendbatches would be necessary
to fix this.

Context: C News Patchdate Mar. 24, 1991, SunOS4.1

-- 
Dave Mack