[PATCH v4] imapd.c: imapoptions: implement idle timeout

ellie timoney ellie at fastmail.com
Tue Sep 27 19:15:07 EDT 2016


Hi Andy,

At this stage the proposed patch only applies to master, whereas in your
thread on info-cyrus you mention you're on 2.5.9.

I do consider this patch -- once landed on master -- to be a possible
candidate for back porting to 2.5, but we're not at that stage yet.

Can we please continue the analysis of your situation in your thread,
and let this thread be about the patch?

Thanks,

ellie

On Wed, Sep 28, 2016, at 01:01 AM, Andy Dorman via Cyrus-devel wrote:
> Don't know if my vote counts, but we are still accumulating over 100 
> idled connections every 24 hours from two accounts being checked by an 
> old (+5 yrs) BlackBerry.
> 
> So I believe an idled timeout could help us there.
> 
> Due to my workload I have not been able to do any network sniffing on 
> the Blackberry connections to irrefutably confirm the cause of the 
> problem, but I wouldn't know what to look for anyway. I am not going to 
> give up capturing the packets though.  At the very least I can probably 
> learn more about IMAP and that is a good thing.
> 
> Andy
> 
> On 09/27/2016 01:07 AM, ellie timoney via Cyrus-devel wrote:
> > On Thu, Sep 22, 2016, at 01:29 AM, Philipp Gesang wrote:
> >> Minutes again, because IMO a fallback between different units of
> >> measure would be confusing.
> >
> > Yeah, I was thinking the same thing. :)  The updated patch looks good to
> > me.
> >
> > So it looks like what we're getting from this is two things:
> >
> > * making the "timeout" limit apply to idling clients
> > * optionally configuring a separate, longer limit specifically for
> > idling clients
> >
> > The former restores old behaviour that looks like it was accidentally
> > lost during the conversion to use a socket rather than signals for idled
> > IPC.
> >
> > The latter then allows administrators to be more lenient with clients
> > that are idling, even if they aren't respecting the
> > restart-after-29-minutes convention.
> >
> > Both of those seem good to me.
> >
> > And they will both also protect Cyrus from the possibility of idling
> > connections dropping out and never being cleaned up properly (though
> > if/when/how this occurs is still subject to speculation).
> >
> > Cheers,
> >
> > ellie
> >
> 


More information about the Cyrus-devel mailing list