> time jumps issued via NTP are a recurring source of trouble. > On our distribution we have detection logic for that and restart > quite a few services if it happens. The monotonic clock avoids that > nicely.
Or does it? The man page says it's "not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock)" -- great -- "but is affected by the incremental adjustments performed by adjtime(3) and NTP". Which sounds to me like NTP might still be an issue? (But: I have no real world experience of this, I'm just reading man pages here.) > Would it make sense to enable the timeout by default? > In the current version of the patch it's disabled (value 0). I'm interested in hearing thoughts on this, particularly with regard to what a reasonable default timeout might be. Though I like the "no behaviour change unless you change configuration" aspect of defaulting to 0. > We plan on rolling it out with a default value of three days > for our systems. That's enough to keep workstations that are left on > over the weekend happy, but short enough to clean up "forgotten" clients > idling on the INBOX/Drafts folder. There are still quite a few > Outlook 2007 installations with broken IMAP IDLE handling in the wild, > so the RFC recommended timeout of 29 minutes is unsuitable. As I understand it, the RFC's recommendation of "29 minutes" applies to clients wishing to avoid being timed out by breaking/resuming idle early, from which I take the implication that a reasonable server might time out connections after 30 mins. But, Outlook... Cheers, ellie On Thu, Sep 8, 2016, at 11:26 PM, Thomas Jarosch wrote: > Hi Ellie, > > On Thursday, 8. September 2016 11:07:54 ellie timoney via Cyrus-devel > wrote: > > I can kind of see a point about the ability to request a monotonic > > clock, such that some sysadmin changing the system time doesn't > > prematurely timeout a bunch of idle connections. Though that doesn't > > seem likely to be a real problem in practice (a: don't do that, b: the > > clients will just reconnect in a bit anyway). > > time jumps issued via NTP are a recurring source of trouble. > On our distribution we have detection logic for that and restart > quite a few services if it happens. The monotonic clock avoids that > nicely. > > > Anyway, the patch applies cleanly, builds fine for me, and passes our > > current tests. I'll try and put together a couple of Cassandane tests > > for the new behaviour and see what shakes out of that. > > Would it make sense to enable the timeout by default? > In the current version of the patch it's disabled (value 0). > > We plan on rolling it out with a default value of three days > for our systems. That's enough to keep workstations that are left on > over the weekend happy, but short enough to clean up "forgotten" clients > idling on the INBOX/Drafts folder. There are still quite a few > Outlook 2007 installations with broken IMAP IDLE handling in the wild, > so the RFC recommended timeout of 29 minutes is unsuitable. > > Cheers, > Thomas >
