Timo Sirainen wrote:
On Wed, 2009-02-04 at 14:51 -0500, Alan Ferrency wrote:
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's what Dovecot does elsewhere. I don't really know why I'm using
non-blocking flock() calls. I guess I should fix that.
That said: I'm not sure whether this will solve our problem in
practice.
Probably not.
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.
IMAP unlocks mbox after each command is done. But POP3 clients typically
just run RETR, RETR, RETR, .. so unlocking + locking again later is just
extra work that slows things down. I guess there could be a timeout that
if no RETR has been run for a few seconds it unlocks the mailbox.
But I've never before heard POP3 clients behaving that way, so I'd like
to know what exactly are they doing. Are they not sending anything? Are
they NOOPing? I don't see any reason for them to be doing either..
We see it (procmail waiting on pop clients doing nothing) when a
connection slows - sometimes to a crawl - on rural U.S. phone lines.
Dovecot usually disconnects them after 10 minutes if the connection
stops, but sometimes that process can drag on for a while. I've watched
these using tcpdump. Analog modems can be quite persistent.
Ken
