Re: Background flist sometimes misses folders?

There is an flistcache that is at the heart of the problem.
If you eliminate that then the problem goes away, but (for me)
the performance is horrible.  I have an uncommitted change
which I'll submit now that tries to invalidate that cache at
the right time, but reportedly it isn't helping.

So, see if the code at HOL CVS helps any.
Harry G. McGavran at has tried this and it didn't work for him :-(

>>>Chris Garrigues said:

 > > From:  Chris Garrigues <[email protected]>
 > > Date:  Fri, 18 Mar 2005 10:37:33 -0600
 > >
 > > has anybody else noticed that the background flist doesn't always find 
all
      the 
 > > folders with unseen messages?  Clicking on the Flist button then finds 
the
      
 > > folders that were missed.
 > > 
 > > As best I can tell, this happens if the new messages that arrived have 
the
      
 > > same message numbers as the ones that were most recently deleted?
 > > 
 > > For instance, I have a mailbox which gets nightly emails from a bunch 
of
 > > different servers.  Every morning there are exactly the same number of 
 > > messages, which I then delete unread because I know what they say.  
This
 > > folder doesn't show up in my sequences window until I click on Flist.  
 > > 
 > > However, on the occasions where one of the systems is down, they do 
show u
     p in 
 > > the sequences window both that day and the following day when the 
system c
     omes 
 > > back up again.  I'm suspecting this is because the list of message 
numbers
      is 
 > > not identical.
 > > 
 > > The fix is probably simple, but I'm not quite sure where to look.  If 
some
     one 
 > > else can find it faster than I can, that would be great!
 > 
 > I believe I've found it.
 > 
 > cvs repository 02/17/2003 [email protected]
 >     ...
 >     flist.tcl - FlistFindSeqsInner added check to eliminate calls to
 >         Seq_Set if the sequence information for a folder hasn't changed
 >     ...
 > 
 > I assume this was done because Seq_Set was too slow.  Have tweaks done 
since
      
 > then improved the situation enough that we can dike this check out?


--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]