Xref: utzoo comp.sys.apollo:7815 news.software.b:6814 Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!wuarchive!cs.utexas.edu!uunet!mcsun!hp4nl!svin02!eba!ebs!wjw From: wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) Newsgroups: comp.sys.apollo,news.software.b Subject: Re: Rn locks active file on Apollos Keywords: postnews, active locked Message-ID: <1081@eba.eb.ele.tue.nl> Date: 5 Feb 91 09:11:31 GMT References: <168@numenor.gtephx.UUCP> <1991Jan31.195615.13448@engin.umich.edu> <4f8ebb1a.1bc5b@pisa.ifs.umich.edu> <1991Feb4.153336.8268@engin.umich.edu> Sender: news@eb.ele.tue.nl (The News system) Organization: Eindhoven University of Technology, The Netherlands Lines: 59 In article <1991Feb4.153336.8268@engin.umich.edu> stealth@engin.umich.edu (Mike Pelletier) writes: =>In article <4f8ebb1a.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu => (Jim Rees) writes: =>>In article <1991Jan31.195615.13448@engin.umich.edu>, => stealth@engin.umich.edu (Mike Pelletier) writes: =>> In article <168@numenor.gtephx.UUCP> yountm@gtephx.UUCP (Marvin Yount) writes: =>> >I'm trying to get Rn set up on our Apollo site. I've got it running =>> >pretty well (up to patch 45), but we have noticed a situation regarding =>> >the locking of the active file... =>> =>> The solution is to forget completely about the Apollo //* filesystem, and =>> install C-news and NNTP on an individual Apollo node, and use rn with NNTP =>> to access the articles. =>> =>>That's one way to do it, but it seems a shame to not use the Apollo =>>distributed file system to read the articles. Using nntp will put a bigger =>>load on both clients and servers and slow down your news readers. I agree completely with Jim. We've got this nice file system, and because things are a little different from the way the creators of the news-system thought they would be, we're going to shoot the bugger with the largest canon they've got in the gulf. =>The articles have to get around the ring one way or another... =>If there is a slowdown, it's imperceptible to anything but a program, =>and doesn't impact the reading of news. Well not completely. If you've got an extensive 'KILL' list (like mine), every new group does get read ahead. The system then really gets penallised?? by having to fetch the articles through NNTP. Generating an Index is also much slower. One more problem gets a solved by sr10.3. It used to be that the maximum number of processes was 64. Now in your concept you've got to run the NNTPD on the system were the news comes in. (Unless you abuse 'another' Unix system for this). At our place this system (our gateway) also runs sendmail, portmap, mountd, nfsd, pcnfsd, atleast 4 DPCI processes, .... and of course the NNTP servers (which go upto 4 when downloading) So You'll understand that processes is among the very scare resources. So the blunt hatchet does really cost you. =>>What we did at Apollo, and what the Engineering School here did until =>>recently, was closer to what Willem suggests. => =>(Not too recently here at Engineering... Over a year or so...) I've patched news this way in 1988, under sr9.7 for the first time. But then other things were causing headaches, so it all got scratched again. In that time I also posted some of the previously described patches. The problem was then, that not everything really left our system. (UP/DOWNloading was done in a different way.) Ciao, Willem Jan Withagen. Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands