If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Not writing out newsrc file often enough

VERIFIED FIXED in M18

Status

MailNews Core
Backend
P1
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: Bienvenu)

Tracking

Firefox Tracking Flags

(Not tracked)

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
accepting.
really accepting this time.
Status: NEW → ASSIGNED

Comment 4

18 years ago
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

Comment 5

17 years ago
David,

Based on Seth's comments, if we do the NNTP connection cache is this going to
disappear?
(Assignee)

Comment 6

17 years ago
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.

Comment 7

17 years ago
M18 and nsbeta3
Keywords: nsbeta3, perf
Target Milestone: M17 → M18

Comment 8

17 years ago
Mail Triage is marking [nsbeta3-]
Whiteboard: [nsbseta3-]
Target Milestone: M18 → Future
(Assignee)

Comment 9

17 years ago
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.

Comment 10

17 years ago
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-]

Comment 11

17 years ago
removing perf keyword since this now seems to be a correctness problem.
Keywords: perf → correctness

Updated

17 years ago
Keywords: mail2

Comment 12

17 years ago
+ per mail triage, also reassign to david.
Assignee: sspitzer → bienvenu
Status: ASSIGNED → NEW
Whiteboard: [nsbeta3+]
Target Milestone: Future → M18
(Assignee)

Comment 13

17 years ago
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

Comment 14

17 years ago
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)
(Assignee)

Comment 15

17 years ago
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
(Assignee)

Comment 16

17 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 17

17 years ago
How to verify this ?
(Assignee)

Comment 18

17 years ago
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

Comment 19

17 years ago
changing qa to suresh
QA Contact: lchiang → suresh

Comment 20

17 years ago
Marking Verified. Tested on 9/29 Branch builds on all platforms.
Status: RESOLVED → VERIFIED

Comment 21

17 years ago
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.