[Dovecot] Full text search improvements

[Timo Sirainen]

On 3.12.2013, at 0.09, Mike Abbott <michael.abbott at apple.com> wrote:

>> Do you think [moving IMAP IDLE connections to a separate imap-idle process] would work for you also?
> 
> Probably.  It always depends on the details.  Forking a new imap process every time there's a little input to read or output to send might perform poorly under load.  Having a pool of ready imap processes could help that, when the configuration permits (e.g. all mail owned by one uid).  It would be interesting to compare client_limit > 1 vs. an idle connection aggregator.

I was thinking that you’d have a pool of imap processes waiting and being reused. Some state would be transferred between the imap-idle and imap processes. And it could work also for non-IDLEing idling connections. Then there needs to be some kind of a good balance of figuring out when to move connection to imap-idle to maximize the amount of time it’s there but also to minimize unnecessary CPU-wasting transfers.. Oh, and this would be possible also with multiple UIDs (although imap-idle might have to run as root then).

> What's so evil about client_limit > 1 besides requiring one uid, the indexer polling I mentioned, and broken fcntl-style file locks?  Or is that enough?

Mainly that there are so many possible reasons for why imap process might block. It’s not possible to make all of them asynchronous. I guess getting rid of the longest waits could help, but I still wouldn’t dare to run that in production.