Newsgroups: news.software.b Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!gjetor!adeboer From: adeboer@gjetor.geac.COM (Anthony DeBoer) Subject: Re: C News and local postings Message-ID: <1991Apr30.135537.23898@gjetor.geac.COM> Organization: Geac J&E Systems Ltd. References: <1991Apr25.181041.6023@mp.cs.niu.edu> <1991Apr25.223301.27280@world.std.com> <1991Apr29.202116.21681@sq.sq.com> Date: Tue, 30 Apr 91 13:55:37 GMT In article <1991Apr29.202116.21681@sq.sq.com> msb@sq.sq.com (Mark Brader) writes: >Geoff Collyer (geoff@world.std.com) writes: >> A change that just missed the last patch and should be in the next one is >> that inews will (finally) invoke newsspool or rnews instead of relaynews... > > [...] >But what this means is that, when such an event happens, sometimes we >have news sitting in in.coming for longer periods than usual, occasionally >even longer than 2 days. It is not tolerable that, when this happens, >locally originated postings should be held up for that length of time. >(Among other reasons is that we use news internally as our corporate >"bulletin board".) > >In recent releases of C News, inews has checked whether /usr/spool/news >was full to the safety threshold before allowing even a local posting; >we have had to disable this. If inews is now to be changed to throw the >local postings in with all the delayed batches in in.coming, it will be >a much greater inconvenience. Geoff and Henry, please do not ruin the >successful news configuration that we have arrived at. I partially second that. The proposed change does mean that when "spacefor articles" is up against the wall, it won't dump a posting in dead.article for the user to try again with later. It'll accept it and post it when it's able to. That much is good. (But what will this change do when "spacefor incoming" is low?) There is the possibility of delaying articles. I have newsrun wake up and check in.coming every 10 minutes (we ran into a problem that my upstream feed could send me a batch, spool up some more news, and send that to me, a few times before newsrun woke up). Also, I'm not turning newsrunning off during the day. The delay before a spooled local article showed up wouldn't be a problem under those circumstances, but of course these aren't the defaults. I'd like to see some way of prioritizing local postings (perhaps by having newsrun sort batches by size and unbatch the smallest ones first?). That way, if "spacefor articles" is low, local articles would tend to get posted ahead of batches from the net. (This could also help allow for propagating local news on multiple local machines). Also, if perhaps this could be extended to a change to the "newsrunning" mechanism, to set a maximum batch size for daytime running, this could allow for people who turn news off during working hours (ie. "newsrunning 10000" would limit unbatching to batches not exceeding 10000 bytes. "Off" would be equivalent to "0", and "on" would mean no limit). I guess the key difference is that Mark B. prefers to let a backlog build up in in.coming, while I like to see in.coming keep flowing. In order to get "local batches", you'd need to maintain at least a minimal flow, so that little batches get run while it holds up big batches. [A low-space-sensitive article-dumper (let's not call it an "expire", since it doesn't do everything C-News expire does nightly) might help here, to effectively automate the process of me typing "df", saying something rude, su'ing, cd'ing /usr/spool/news/alt/whatever, and rm'ming 100 or so of the oldest articles. Something like that could really help even out some of the net.sunspots or whatever it is that causes news surges.] A minor related quibble is that spacefor should be capable of checking inode availability, since that's what you run out of first in /usr/spool/news often enough. Anyway, I hope these ideas aren't completely silly and I haven't trodden on anyone's toes. flames | mail. -- Anthony DeBoer NAUI#Z8800 | adeboer@gjetor.geac.com | Programmer (n): One who Geac J&E Systems Ltd. | uunet!geac!gjetor!adeboer | makes the lies the Toronto, Ontario, Canada | #include | salesman told come true.