Closed Bug 29743 Opened 24 years ago Closed 24 years ago

Not writing out newsrc file often enough

Categories

(MailNews Core :: Backend, defect, P1)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: Bienvenu)

Details

(Whiteboard: [nsbeta3+]Fix in hand)

I'm writing out the newsrc file too often.

namely, when the nsNNTPProtocol instance gets destroyed, which happens
frequently because we don't have a nntp connection pool.

something to work on when I get time.
moving to m16.
Target Milestone: M16
really accepting this time.
Status: NEW → ASSIGNED
Triage to M17.  Please add beta2 keyword if this must make beta2.  Please let me 
know if this must be done by M16 feature freeze.
Target Milestone: M16 → M17
David,

Based on Seth's comments, if we do the NNTP connection cache is this going to
disappear?
it will disappear, and re-appear as "we're not writing out the newsrc file often 
enough". So there will still be a problem. We should be writing out the newsrc 
file on a timer, like 4.x, e.g., every 5 or 10 minutes.
M18 and nsbeta3
Keywords: nsbeta3, perf
Target Milestone: M17 → M18
Mail Triage is marking [nsbeta3-]
Whiteboard: [nsbseta3-]
Target Milestone: M18 → Future
Now the bug is that we never write out the newsrc file, unless we shutdown and
aren't leaking nsNNTPProtocol objects. That seems rather risky to me. People
lose the readness of news messages with this bug, which is data loss.
ok. changed the summary and removed the nsbeta3- for reevaluation.
Summary: writing out newsrc file too often → Not writing out newsrc file often enough
Whiteboard: [nsbseta3-]
removing perf keyword since this now seems to be a correctness problem.
Keywords: perfcorrectness
Keywords: mail2
+ per mail triage, also reassign to david.
Assignee: sspitzer → bienvenu
Status: ASSIGNED → NEW
Whiteboard: [nsbeta3+]
Target Milestone: Future → M18
accepting. Adding Alec to cc list in case he has any thoughts on this. Timers
are probably the way to go, probably hanging off the nntp server object. An
other choice would be to keep track of how many read/unread changes have been
made and commit after x changes - this would have to take ranges into account,
probably...
Status: NEW → ASSIGNED
hrm.. I guess a timer is the best solution, as long as we can some how avoid
writing the file if it hasn't changed (it would be wrong if we hit the disk no
matter what, ever x minutes)
setting to p1 because I have a fix in hand and don't want anyone nsbeta3
minussing this bug.
Priority: P3 → P1
Whiteboard: [nsbeta3+] → [nsbeta3+]Fix in hand
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
How to verify this ?
1. Open a newsgroup.
2. Mark some messages read (or unread)
3. Wait 5 minutes or 6 minutes
4. Kill netscape/mozilla without shutting down app(simulates crash)
5. Start up again, open newsgroup, and see if the read/unread state is remembered
changing qa to suresh
QA Contact: lchiang → suresh
Marking Verified. Tested on 9/29 Branch builds on all platforms.
Status: RESOLVED → VERIFIED
removing mail2 keyword.
Keywords: mail2
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.