Re: [Pan-users] Re: Bug in Headers pane?

[Ron Johnson]

On 04/04/2011 06:47 PM, Duncan wrote:
> Ron Johnson posted on Mon, 04 Apr 2011 17:19:56 -0500 as excerpted:
[snip]
> But you seem to be seeing it happen with just the one pan instance
> running, just leaving a group with a download-and-save job running, and
> coming back to it?  The download-and-save job that WAS marking as read as
> it went, now is not doing so, with everything downloaded-and-saved since
> you left the group again marked as unread.  That's strange, indeed, and is
> definitely a bug.

> > > There is a long-standing bug with articles being incorrectly marked
> > > read or unread, but I've never been able to reproduce it with enough
> > > regularity to track it down.
> > >
> > > If you can reproduce it 100%, please write down the algorithm and post
> > > it here so we can finally get it fixed.
> > Exactly what I specified in the OP work *every* time.

A twist:

Downloading stuff at the moment.  Did a Group Switch and then returned 
to the original group.  The articles *are* "flipping" from Bold to Regular.

Since this particular set of articles is only posted to a single group, 
I wonder if the problem lies only with cross-posted articles.

Will have to experiment more.

> > Also, a bug that I've know about for some time is that Marked Read
> > status don't get flushed to disk until you change groups or politely
> > exit.  The power flickered this morning and when I went back into pan,
> > all the articles that I had marked as read were now unread.
>
> That's deliberate, and actually an improvement from how the pan rewrite
> used to work, only flushing at pan exit.  I fought hard to get it back to
> behaving as old-pan had, at least flushing when the group changed.  That
> allowed me to quickly switch groups back and forth every so often, locking
> in the state when I did so, instead of having to quit pan entirely in
> ordered to lock it in.
>
> Charles argued that flushing at every change was a potential performance
> issue, and that such frequent writes carried a risk of its own, since a
> crash in the middle of a write could mean loss of data as well --
> potentially loss of the whole index file thus loss of status for ALL
> groups, not just one.

That's why pan needs persistent storage: BerkleyDB, sqlite, etc, etc.

>                       Doing it only when switching groups was at least
> predictable, and allows users to reload the group (actual switching groups
> isn't needed, I discovered, simply clicking on the group as if you're just
> switching to it, reloads it, flushing current state to disk) periodically,
> to flush state.
>
> Something between those two extremes, flushing state say on a 5/10/20/30-
> minute timer. or by count, every 20/50/100/whatever

A checkpoint.

>                                                      posts read, or some
> such, could be argued.

If you have a persistent backing store and all changes in memory, then 
when the checkpoint is reached then pan would quickly update the backing 
store with any changes instead of deleting the state file and then 
dumping all state to disk.

>                        That wouldn't have the risk or performance lag of
> doing it every post, but would still avoid losing an hour's worth and
> hundreds of posts worth of state if someone forgot to reload the group
> every so often.

Or a jillion downloaded headers.

As a DBA, I expect my data to be there after a crash.

As a user, I prefer consistent UI speed instead of 
fast-freeze-fast-freeze...

> But it wouldn't be as predictable as reloading the group manually,
> either.  If the crashes are somewhat triggerable, say by doing something
> specific in another program, bringing down the entire system including
> pan, one can learn not to manually switch or reload groups at the same
> time as one does whatever other risky action.  But some other automatic
> timer would arguably be much less predictable and thus much more likely to
> eventually happen at the wrong moment, when the other risky action had
> just been triggered as well.
[snip]
> Meanwhile, there's another possibility as well.  That of a local issue due
> to a bad filesystem.  What filesystem type are you running on the
> partition storing the pan data?  Have you tried doing a full fsck
> (preferably while unmounted) on it, recently?  If so, was any filesystem
> damage detected and corrected?

xfs on a brand new set of disks.  As mentioned on another post, it may 
only happen with cross-posted files.

--
"Neither the wisest constitution nor the wisest laws will secure
the liberty and happiness of a people whose manners are universally
corrupt."
Samuel Adams, essay in The Public Advertiser, 1749