RumorMill v1.2.1
Copyright © 1996-1999, Peter N Lewis and Jim Calvin.
RumorMill Frequently Asked Questions (FAQ)
- Why does RumorMill crash when a newsfeed connects to deliver articles?
- Why doesn't RumorMill add articles to the database?
- Why does my database just keep growing?
- Is RumorMill year 2000 ready?
- How does a moderator post an article to a moderated group?
This typically happened when a remote news server connected to RumorMill version 1.1 and attempted to stream articles to RumorMill. Version 1.1.1 of RumorMill added a patch that prevented this crash by refusing to accept streamed articles. Version 1.2.1 of RumorMill correctly handles streaming newsfeeds.
There are several possible reasons for this problem which include:
- Date/time mis-match between the computer running RumorMill and the client computer.
If a difference in date and time exists between the two computers which is greater than one day (24 hours), RumorMill will reject the article because of a "bad date." This problem can be verified by checking the "Rejected Article" file in your Database folder.
- Improperly configured Remote Servers
Check the documentation for details.
- Improperly configured Site address restrictions
Check the documentation for details.
- Incoming articles are malformed
Improperly formed articles are rejected and logged in a file called Rejected Article in the Databases folder. Check the contents of this file to see if malformed articles are being rejected. [Logging rejected articles may be enabled/disabled by the Log Rejected Msgs preference.]
- Disk space is low
RumorMill attemps to avoid completely filling up a disk volume. A preference Disk Space Threshold specifies how much disk space RumorMill should leave available on each of the volumes used to store RumorMill files and databases. When the disk space drops below this threshold, RumorMill will no longer accept articles to be added to the database.
The RumorMill database will continue to grow until enough time passes for articles start expiring. If RumorMill is left running continuously, once per day, RumorMill will perform an expiration pass over the database. Because databases can become large and the processing requires quite a bit of processor time, the expiration processing is broken into parts and performed over several days. [Follow this link for a detailed description.]
If there isn't enough disk space available to periodically compact the database (by copying parts of it to a new file), RumorMill compacts the database in place. When this is done, the database files do not shrink in size as a result of the expiration process. However, eventually your database should reach a steady-state size. Unless of course you have so many active groups that the incoming articles grow your database until the disk is full, or the maximum file size (2GB) is reached. [For a more complete discussion, follow this link.]
RumorMill 1.1.1
Strictly speaking, RumorMill 1.1.1 is not year 2000 ready. Since Macs don't have a problem with the year 2000, why does RumorMill? Well, the NNTP specification has its own way of dealing with the year 2000. That is, the spec says that 00 is to be interpreted as 2000. RumorMill is compliant to this specification and therefore handles the year 2000 properly. However, RumorMill clients (news readers), could, through certain commands (the NEWNEWS and NEWGROUPS NNTP commands), break the specification and send 2000 instead of 00. In this case RumorMill 1.1.1 will not return the correct information.
RumorMill 1.2
RumorMill 1.2 is fully year 2000 (Y2K) ready.
The moderator must add an "Approved: <moderator's EMail address>" header to each article she or he posts into a moderated group.
[ Stairways Home | Subject Index |
Feedback ]