[horde] Best timing settings for Horde ActiveSync

Mon Jan 12 21:03:33 UTC 2015

Citeren Patrick De Zordo <patrick at spamreducer.eu>:

>> >> I've tried to debug a bit the things..
>> >> Please download this file:
>> >>
>> https://www.dropbox.com/s/tsdjfeaumhiy79p/BUG%20OL%20slow%20resp
>> onse%
>> >> 20on%20new%20message.zip?dl=0
>> >>
>> >> This is the timeline:
>> >> - I have connected 1 Android and 1 OL2013 client via ActiveSync to
>> >> our server (we are using Horde GIT version from some weeks ago).
>> >> - The problem is happening just with the OL2013 client
>> >>
>> >> In "9A9F4000B00444C8BC2C1E40D55ED522_sleeping.txt" log file you can
>> >> see some tailed details about the OL2013 client
>> >>
>> >> OL2013 is working normal till 10:07:32: You can see "Sleeping for
>> >> 15 seconds."
>> >> In log again and again..
>> >> From 10:07:32 - 10:12:50 -> nothing, sleeping, winter sleep..
>> >> From 10:12:55 - 10:18:04 -> nothing, sleeping, winter sleep..
>> >> From 10:18:05 - 10:23:23 -> nothing, sleeping, winter sleep..
>> >> From 10:23:23 - 10:28:45 -> nothing, sleeping, winter sleep..
>> >> From 10:28:50 - 10:34:08 -> nothing, sleeping, winter sleep..
>> >> From 10:34:13 - 10:39:31 -> nothing, sleeping, winter sleep..
>> >>
>> >> Then 3 times:
>> >> 2015-01-12T10:39:32+01:00 INFO: [3158] Sleeping for 15 seconds.
>> >> 2015-01-12T10:39:47+01:00 INFO: [3158] Sleeping for 15 seconds.
>> >> 2015-01-12T10:40:04+01:00 INFO: [3158] Sleeping for 15 seconds.
>> >>
>> >> From 10:40:23 - 10:45:41 -> nothing, sleeping, winter sleep..
>> >>
>> >> Then again lot of times:
>> >> 2015-01-12T10:46:09+01:00 INFO: [10625] Sleeping for 15 seconds.
>> >> 2015-01-12T10:46:25+01:00 INFO: [10625] Sleeping for 15 seconds.
>> >> ..
>> >>
>> >> On 11:30:xx - I have marked 1 message as read on smartphone..
>> >> From 11:30:16 - 11:48:24 -> nothing, sleeping, winter sleep.. (at
>> >> 11:45:25 - I
>> >> have deleted another 2 messages on smartphone, just to clarify log
>> >> lines) From 11:48:28 - 12:08:05 -> nothing, sleeping, winter sleep..
>> >> From 12:08:10 - 12:13:28 -> nothing, sleeping, winter sleep..
>> >>
>> >> OL2013 is showing "All folders are up-to-date" all the time..
>> >>
>> >> So what is maybe causing this big delays?
>> >
>> > What is your webserver configuration? Could it be that the process
>> > that is looking for changes in the mailboxes is killed before the
>> > $conf[activesync][ping][heartbeatmax] (in your case, 2700 seconds) is
>> > elapsed? That might explain why some devices (which use a lower
>> > heartbeat interval) may not notice anything strange, but one that does
>> > use the maximum allowed time, to show erratic behaviour. The requests
>> > will just timeout in that case, meaning your Outlook client expects to
>> > be informed of any changes, but the process that should do that, died.
>> >
>> > Note that you should configure the idle time for your PHP processes
>> > (and connections to them) to at least an hour, since ActiveSync allows
>> > this to be up to 59 minutes. In my case, I had to set
>> >
>> >     ProxySet timeout=3600
>> >
>> > in my Apache config (I use mod_proxy_fcgi to connect to php-fpm) in
>> > order to prevent this.
>> >
>> >> Could this be a BUG, so I could create a new BUG?
>> >
>> > I suspect this is just a process timing out.
>>
>>
>> I agree. There is nothing in that log (other than the weird, non-sequential
>> order of some of the timestamps and process
>> numbers....) that looks like a bug to me at all.
>>
> Something strange I can't understand is WHY is there no "Sleeping for 15
> seconds" log entry anymore?

Most likely, the process that was checking for changes during the  
heartbeat interval was terminated.

Simplified, the way an ActiveSync SYNC (or PING) works, is that the  
folders that are synchronized to the device are checked for changes.  
If nothing has changed and less than the heartbeat interval has  
elapsed since receiving the SYNC, the process sleeps for  
$conf[activesync][ping][waitinterval] seconds (in your case, 15  
seconds) and checks again. This repeats until a change is detected or  
the heartbeat interval elapses. Only then a response to the SYNC is  
sent to device. If the process is killed before the reply is sent,  
devices will not know about that until the heartbeat interval elapses  
and will remain oblivious about any changes.

Since another device seems to work correctly with a shorter heartbeat  
interval, chances are that something in your PHP and/or Apache  
configuration is killing the process before the heartbeat interval  
ends. A quick-and-dirty way to see if this might be the problem, would  
be to reduce both $conf[activesync][ping][heartbeatmax] and  
$conf[activesync][ping][heartbeatdefault] to 480 seconds (470 seconds  
seems to work on your Android device). If after that the problem no  
longer occurs, you need to look into your Apache and/or PHP  
configuration if something is killing long running processes.

> Horde is sleeping 15sec, right? So, also IF the HTTPS connection would
> timeout, Horde would sleep for 15sec.. I think..

No, this is not how this works. It's likely not the connection that  
times out, it is the process that is checking for changes that is.  
Remember that you need to allow for at least one Apache server  
processes for each ActiveSync device that is connected (they will keep  
the connection occupied).

Device sends PING -> new message arrives within heartbeat interval ->  
server replies with 'change detected'
- or -
Device sends PING -> heartbeat interval passed without changes ->  
server replies with 'nothing changed'

-- 
This message was sent from a mailinglist subscription address.
For off-list replies, you must remove the address extension.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 11647 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20150112/c4b0fb6c/attachment.bin>