[Dovecot] pop3_lock_session question

[Ken A]

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