[Dovecot] v2.0.0 released

[Timo Sirainen]

On Wed, 2010-09-15 at 10:12 +0200, Axel Luttgens wrote:
> Here, with dovecot 2.0.2, client_limit seems to default to 1 for services imap and pop3.
> Trying client_limit=10 for imap, I get:
> 
> 	dovecot[46911]: imap(testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service

Yes.

> 	dovecot[46286]: lmtp(46334, testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service
> 
> and one needs to define client_limit=1 for lmtp as well.

Yes, this is intentional. client_limit=1 default is good for pop3/imap,
but for lmtp and non-mbox format a larger client_limit is better because
latency doesn't matter that much.

> This behavior seems to have been enforced in mbox-storage.c with http://hg.dovecot.org/dovecot-2.0/rev/28c3486864f6, and comes with following comment: "/* we can't handle locking related problems. */".
> 
> This is thus rather new.
> But I couldn't find any information on the list related to those "locking problems".
> Is it really needed to be so stringent with mbox format?
> Or was it jut intended to be a temporary workaround?

The problem is that with mbox format the mbox file can be locked for a
long time. So for example two clients handled by the same process may
attempt to write to the same mbox:

 - Client 1 write-locks mbox file and goes back to ioloop waiting for
the message data to arrive.
 - Ioloop starts handling client 2 connection, which also tries to save
message to same mailbox and tries to write-lock the same mbox file.

Now the second client keeps blocking on the write-lock and waiting for
client 1 to release the lock, but since 1 is handled by the same
process, this won't happen.

This problem doesn't happen with any other mailbox format.

Maybe some day in future there's a way to avoid this by having the code
notice early that the mailbox is locked and go back to ioloop instead of
block.