On 3.12.2013, at 0.09, Mike Abbott michael.abbott@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.