[Dovecot] pop3_lock_session question

[Alan Ferrency]

Rob Mangiafico <rmang at lexiconn.com> wrote:
>On Wed, 4 Feb 2009, Timo Sirainen wrote:
>> On Wed, 2009-02-04 at 11:17 -0700, Mark Costlow wrote:
>>> Hello, I'm preparing to convert from qpopper + UW-IMAP to dovecot.
>>> So far testing has gone very well.  One problem we haven't figured
>>> out is that long-running POP sessions keep the mailbox locked, so that
>>> the MDA times out while trying to deliver.
>> ..
>>
>> Switch to Maildir and the problem goes away.
>
> We see this as well with mbox and pop3 accesses where some pop3 clients do
> not logout (iphone's are the worst offenders) for 30-90 minutes it seems.
> Timeout settings in dovecot.conf do not seem to help. procmail backs up
> waiting to get access to the inbox to deliver mail.

We are having the same problem. It's not a problem with imap, only
with pop3.  We're using deliver as the MDA.  We're also using flock()
locking for the mbox: is that what everyone else is using as well?

Migrating our servers to maildir globally is also not an option for
us.  In some cases, even convincing customers to use IMAP isn't going
to work.

One problem which might be making this worse than it needs to be, is
the fact that mbox_lock_flock in mbox-lock.c is not using a blocking
flock(); instead, it's polling for a non-blocking lock.  This technique
can cause lock starvation, if another process is dropping the lock and
picking it back up again frequently: other processes will only see the
lock as being available if they happen to poll for the lock at just
the right instant.

A better technique to use here, if it's adequately cross-platform,
would be to set an alarm() for the max_wait_time, and use a blocking
flock().  If the alarm times out and you don't have a lock, it's a
timeout.  In the meantime, you're guaranteed to eventually get the
lock, if it is dropped.


That said: I'm not sure whether this will solve our problem in
practice.

Why doesn't this happen with imap?  Why can't we make pop3 do what
imap does?  Even if it's inefficient, it's better than hanging all
incoming mail delivery while deliver eats up our local concurrency
limits.

Thanks!

Alan Ferrency
pair Networks, Inc.
alan at pair.com