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