Gnus development mailing list
 help / color / mirror / Atom feed
* 4000000 unread articles
@ 1997-08-12 22:44 Loren Schall
  1997-08-13 16:26 ` Alan Shutko
  0 siblings, 1 reply; 2+ messages in thread
From: Loren Schall @ 1997-08-12 22:44 UTC (permalink / raw)


I ran into an interesting anomaly this last week.

It had been a few days since I'd last read news so when I brought up
Gnus, I pushed it to the back.  NoCeM usually takes a few minutes to
run.  Over the next hour or so I checked it occasionally, still running.

About an hour and a half after I'd started it, I notices emacs had
crashed.  I don't remember the error message, but something lead me to
believe Emacs had run out of resources.  So I restarted Emacs and Gnus,
assuming it would start up from where it had left off and finish.  About
an hour later I noticed it had crashed a again, in NoCeM.  So I disabled
NoCeM and started things up again.  This time I got all the way to my
topic buffer.  I saw that a lot of groups have more than 3,000,000
unread message, a couple more than 4,000,000.  I didn't really think
much of it.  I'd seen large jumps in article numbers from this NNTP
server before.  Not this big, but... I wasn't surprised.  Before, I'd
just enter each group, and after a short pause, discover that the real
number of new articles was something more reasonable.

I was surprised to find a mail message from my service provide, that
they had terminated my emacs process, twice, because it was using too
many resources.  150M of virtual memory and 45% of the CPU.

Somewhere in the Info files, I found a note that NoCeM was a memory hog,
so I hand munged ~/News/NoCeM/active, before reactivating NoCeM.
Everything seem to be back to normal.

A few days later, I wanted to look at some old articles.  When I entered
the group I didn't get a summary buffer right away.  Oh, I thought, this
must be one of those groups with the bogus articles numbers.  It'll take
a couple of minutes.  I pushed my emacs window to the back and did some
other stuff for a few minutes.  When I returned, my service provider had
killed emacs again.

Any suggestions?  I'm not afraid to dink with the code, if somebody'll
tell me where to look.  There aren't really 4,000,000 unread articles,
but Gnus (and tin and pine, according to my service provider) seem to be
expecting articles from 1 to whatever.  Is this a limitation of NNTP?

-- 
Loren Schall
schall@ateng.az.honeywell.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 4000000 unread articles
  1997-08-12 22:44 4000000 unread articles Loren Schall
@ 1997-08-13 16:26 ` Alan Shutko
  0 siblings, 0 replies; 2+ messages in thread
From: Alan Shutko @ 1997-08-13 16:26 UTC (permalink / raw)
  Cc: ding

>>>>> "L" == Loren Schall <schall@saifr00.ateng.az.honeywell.com> writes:

L> Any suggestions?  I'm not afraid to dink with the code, if
L> somebody'll tell me where to look.  There aren't really 4,000,000
L> unread articles, but Gnus (and tin and pine, according to my
L> service provider) seem to be expecting articles from 1 to whatever.
L> Is this a limitation of NNTP?

This happens if the provider resets the article numbers (as mine tends
to do for no known reason).  Gnus then tries to set up a really huge
array with space for info for each article, I believe.  This go boom.

Tin and some other newsreaders I've tried can handle this fine, which
explains my newsadmins nonchalant in changing article numbers by a
few million every so often.  8^(

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
If wishes were horses, then beggars would be thieves.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1997-08-13 16:26 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-12 22:44 4000000 unread articles Loren Schall
1997-08-13 16:26 ` Alan Shutko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).