Janne Peltonen wrote:
Hi.
We are going to upgrade to Cyrus v2.3 sometime before midsummer.
Currently, we are running an old, old version of Cyrus with a plaintext
mailboxes file. Now and again, an imapd process gets stuck and keeps the
writelock on the mailboxes file - so we have to kill the stuck process
manually before anybody else can complete any mailbox manipulation
procedure. This is, needless to say, annoying.
While planning this upgrade, my colleagues have been asking me whether
the mailboxes database in current Cyrus is monolithic in the same way:
if one process keeps a lock to one part of it, does it in fact have all
of the file locked? To be more exact, is this the case with the Skiplist
db format? We can't use berkeley because it doesn't work well with
clustering and GFS (see previous posts on the subject, and pse don't
tell me you can't cluster Cyrus).
Cyrus doesn't use byterange locking for plaintext mailboxes.db. It just
relies on advisory locking of the whole file, and it updates the file
atomically by creating a new version and renaming it. Running 1.5.14,
there used to be some locking issues where, much as you describe, we'd
end up having to figure out which imapd wouldn't release the lock and
kill it. My previous employer upgraded from a single server running
1.5.14 with plaintext mailboxes.db to a cluster running 2.1.17 with
plaintext mailboxes.db and is no longer experiencing those locking
issues. I can only assume that at some point between 1.5.14 and 2.1.17,
Larry or Rob or Ken or someone fixed that problem.
Thanks,
Dave
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
