Xref: utzoo gnu.emacs.gnus:1033 news.software.nntp:1003 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!cedman From: cedman@golem.ps.uci.edu (Carl Edman) Newsgroups: gnu.emacs.gnus,news.software.nntp Subject: Re: gnus broken!? Message-ID: Date: 21 Dec 90 20:44:19 GMT References: <1990Dec5.181808.10759@mprgate.mpr.ca> Organization: University of California, Irvine, USA. Lines: 78 Nntp-Posting-Host: lynx.ps.uci.edu In-reply-to: lee@wang.com's message of 21 Dec 90 17:55:06 GMT In article lee@wang.com (Lee Story) writes: parker@mprgate.mpr.ca (Ross Parker) writes: >I have just installed Cnews (PATCHDATE 7-Sep-1990) and nntp version >1.5.10 on our news serving system. Until this change, we had been >running Bnews 2.11.?. This change has caused gnus to break... everyone >using gnus reports that it as soon as a newsgroup is selected, gnus >will hang. One user has reported that newsgroups with less than 4 >articles in them work fine (this is the number of subject lines that >is displayed...) >Anyone seen this? Yes, sort of. I build gnus for SCO V.3.2 and emacs 18.55, using the "tcp.c" program from the gnus distribution to access the remote nntp server. When I run "tcp" to talk to nntp interactively, it works JUST FINE!! When run from gnus (nntp.el/nntp.elc OR tcp.el/tcp.elc) it displays the group list (after a painfully long time), but if a group of more than two of three articles is selected, gnus hangs. I've tried reducing the number of requests parameter, as the installation documentation suggests (from 400 down to 100, 20, and 10). I've tried setting "nntp-buggy-select". It's time for SERIOUS debugging. I'd love to see a post if anyone else has solved this. This should be around my 30th post (not counting a large number of private mails) on this newsgroup and news.software.nntp that solves this problem. This has been asked a huge number of times. I understand that some newsservers throw away messages after 2 or 3 days, but there has to be a way to prevent the reposting of this solution twice a week. OK, from now on I will just repost this file again every time this question is asked (Only updateing the number). The problem is a bug in the NNTP software revision 1.5.10. It didn't exist in 1.5.9 and has been promised to be fixed in 1.5.11. Basically the problem is that NNTP mixes 2 levels of file access. It uses buffered IO, and at the same time uses select(). Usually this doesn't cause any trouble as long as the sender of commands doesn't send them faster than they can be processed, so that the buffer is always empty when NNTP looks for the next command. But GNUS requires a large number of commands at a decent speed, so it sends up to 400 commands ahead before waiting for a reply. To solve this problem there are several possibilities. First: If you don't have access to the NNTP server software, then this is your only possiblity. Change nntp-maximum-request to 1 , and set nntp-buggy-select to t in your "~/.emacs" file. To do this add lines like this: (setq nntp-maximum-request 1 nntp-buggy-select t) This will work, but makes GNUS very slow. You wont want to read large newsgroups like this. You probably will stop using GNUS. You may even stop reading news. (Every reader judge for himself , if that would be an advantage :-). Second: This is the most common and easiest way to fix the problem, which this NNTP server uses, and which seems to be fairly wide spread. Select is used by NNTP to time out connections. If you disable the timeout feature, this solves the problem. To do this find where TIMEOUT is defined in the source, and undefine it. Now there wont be any timeouts, select wont be used and GNUS is happy. The disadvantages of this approach is that connections don't timeout anymore, and that it is slightly cludgy. Third: You can really fix the problem by rewriting the timeout parts of NNTP. If anyone has done this, please let me know. Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu