oblem
since upgrading to the latest versions using skiplist for seen.db
Harris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Jay Levitt
Sent: Wednesday, December 18, 2002 10:04 AM
To: Lawrence Greenfield; [EMAIL PROTECTED]
Subject: Re: Updating /seen
> I have no plans on changing how seen state is currently cached. We haven't
> had any complaints from our users and (now that we found the cyrusdb_flat
> problem) it doesn't seem like it is that huge an uissue for most other
> sites, either.
Interesting. Can you tell me the semantics of the cach
--On Friday, December 13, 2002 12:52 AM -0500 Jay Levitt
<[EMAIL PROTECTED]> wrote:
I believe I've fixed this bug in CVS (did it a few days ago, actually)
and it'll be in the next release.
If I understand correctly, this fixes the flat-file seen implementation,
but not the underlying problem, w
> I believe I've fixed this bug in CVS (did it a few days ago, actually)
> and it'll be in the next release.
If I understand correctly, this fixes the flat-file seen implementation, but
not the underlying problem, which is that updates to seen are deferred until
the connection is closed. Am I fol
To keep everyone up to date (Andrew already knows this):
I was wrong, everyone else was right. The flat backend has a bug in it
that if a given seen file frequently reuses the same inode (as will
happen frequently on lightly loaded systems) you run into this strange
behavior with seen state betwee
Date: Fri, 15 Nov 2002 15:44:45 +1100
From: Andrew McNamara <[EMAIL PROTECTED]>
[...]
BTW, have you looked at Andrew Tridgell's Trivial Database? It uses mmaped
files and spin-locks to achieve good write performance, although I don't
think resilience in the face of crashes was a high
--On Friday, November 15, 2002 8:49 PM +1100 Andrew McNamara
<[EMAIL PROTECTED]> wrote:
I suspect there is a bug in the flat-file seen implementation. Each
process opens the seen file and holds this file descriptor open. Then one
process wants to update the file. It does this by writing a new fil
Andrew McNamara wrote:
With skiplist, this problem no longer occurs (the skiplist database
makes changes made by other processes visible immediately). However,
another problem remains: updates are defered for performance reasons. So
one session will update the seen list, and the other processes w
>I don't use OE but I experienced the same (or similar) problem with
>mozilla: since it uses many concurrent connections to the server, seen
>messages came back as unseen various times, and it was very annoying.
>Switching to skiplist almost solves the problem (at least it did for
>me): since I
Lawrence Greenfield wrote:
Try using skiplist for the seen.db
It doesn't really solve the problem but it masks it well enough.
From my understanding, changing to skiplist really shouldn't change
the visible behavior at all. But I've been wrong before.
It would be possible to flush the see
>BTW, have you looked at Andrew Tridgell's Trivial Database? It uses mmaped
>files and spin-locks to achieve good write performance, although I don't
>think resilience in the face of crashes was a high priority. However the
>architecture-dependent spin lock code may be handy if you ever decide
>to
>A lot of problems also result when people try to run the application on
>more than one computer hitting the same NFS server. But things that drive
>us application writers mad is the idea that rename() can return failure but
>have actually happened; and if you're trying to write a reliable
>app
--On Friday, November 15, 2002 2:40 PM +1100 Andrew McNamara
<[EMAIL PROTECTED]> wrote:
In general none of Cyrus will necessarily work over NFS. If you're only
accessing the NFS store from a single client, things have a much better
chance of working---
By single client, do you mean a single NFS
>In general none of Cyrus will necessarily work over NFS. If you're only
>accessing the NFS store from a single client, things have a much better
>chance of working---
By single client, do you mean a single NFS client hitting the NFS server?
If so, this is guaranteed in our configuration.
>but
--On Friday, November 15, 2002 12:52 PM +1100 Andrew McNamara
<[EMAIL PROTECTED]> wrote:
What's the general feeling on the skiplist implementation used in
conjunction with Sun and NetApp's NFS (we're locked in to using this
combination for various reasons)? Would you be more or less likely to
tru
>Try using skiplist for the seen.db
>It doesn't really solve the problem but it masks it well enough.
>
>From my understanding, changing to skiplist really shouldn't change
>the visible behavior at all. But I've been wrong before.
I'll try to test it here and let you know. My reading of the code s
Date: Thu, 14 Nov 2002 09:38:27 +0100
From: Luca Olivetti <[EMAIL PROTECTED]>
Andrew McNamara wrote:
> I realise this is an old known problem, but I've spent some time searching
> list archives, and other sources looking for an answer. Any help anyone
> can provide will be grate
Andrew McNamara wrote:
I realise this is an old known problem, but I've spent some time searching
list archives, and other sources looking for an answer. Any help anyone
can provide will be gratefully received.
Try using skiplist for the seen.db
It doesn't really solve the problem but it masks
Outlook Express users are complaining that their message \Seen status is
"lost". Snooping traffic, I see that OE is opening a second connection. In
duplicating OE's behaviour by hand, I'm finding that I'm more confused
than ever about Cyrus's behaviour. We're using Cyrus 2.1.9 on NetApp
mounted dis
19 matches
Mail list logo
