[horde] new tests for Re: problem ActiveSync Android Event with end date

Michael J Rubinsky mrubinsk at horde.org
Wed Feb 5 14:58:58 UTC 2014


Quoting Steffen <skhorde at smail.inf.fh-bonn-rhein-sieg.de>:

> On Wed, 5 Feb 2014, Steffen wrote:
>> On Fri, 31 Jan 2014, Michael J Rubinsky wrote:
>>> Quoting Steffen <skhorde at smail.inf.fh-bonn-rhein-sieg.de>:
>>>> On Fri, 10 Jan 2014, Steffen wrote:
>>
>>>> 12:03 one event repeated each 4th week end on 28th March
>>>
>>> ^^^ This event is NEVER sent to the server, at least not in the  
>>> log you posted.
>>
>> OK, thanks for checking the logs.
>>
>>>> Most interessting is that the time stamp gets 1 hour back ??? From 12:04
>>>> to 11:04. It's another PID. During that phase, no Calendar entries in
>>>> the log. I also had log entries another time with a line:
>>>> Skipping @Calendar@ because it is not PINGable.
>>>>
>>>> Then there is a jump in the hour again with the same PID at the time
>>>> I remove the repeated event:
>>>> 2014-01-30T11:08:01+00:00 DEBUG: [1671] I       </Data>
>>>> 2014-01-30T11:08:01+00:00 INFO: [1671]
>>>> Horde_Core_ActiveSync_Driver::changeMessage(@Calendar@,  ...)
>>>> 2014-01-30T12:08:01+01:00 INFO: [1671] Updating state during change
>>>> 2014-01-30T12:08:01+01:00 DEBUG: [1671] I      </Add>
>>>>
>>>> And with the "12" hour logs, the "Calendar" stuff appears again.
>>>>
>>>> The log is attached

The log shows absolutely no calendar (or any other collection for that  
matter) data being transmitted either to or from the server.

>>> I have no idea what is going on. Your synclog also seems to  
>>> indicate your client is issuing multiple, identical requests.  
>>> Given the fact that the event in question is not even sent to the  
>>> server from the client, this seems like a client bug.
>>
>> Hmm, I will try this with other setups.
>>
>> Do you have an idea, why the log time stamp warps one hour back  
>> into the past and back into current again? Is Horde switching to  
>> UTC maybe? The 1 hour is the difference of the local server time to  
>> UTC.
>>
>> Is it possible that the time difference break the acceptance of  
>> some request / response? I mean, several SYNC implementations add  
>> sanity checking that a SYNC message is in a defined time frame.  
>> Maybe Horde tags responses with a timestamp, which is one hour too  
>> old?
>
> I have re-tested with a Nexus5 with Android v4.4.2 and an upgraded  
> Horde, now Horde_ActiveSync v2.12.3.
>
> On both versions of Horde_ActiveSync v2.12.1 and v2.12.3 the Nexus5  
> Exchange Server Force Closes as soon one triggers a sync with the  
> repeated event with repeat end date. It happily works with other  
> events. Attached you'll find the log of the 2nd attempt Nexus5 with  
> v2.12.3. Before the test I removed the ActiveSync device from Horde  
> via Admin GUI.

Cannot reproduce.

> Events with repeat end date won't work on v2.12.3 with my personal  
> Android v4.2 device still.

Cannot reproduce on a 4.2 ROM, or any other device, for that matter.

> The Nexus5 log starts with the log time "2014-02-05T07:52:44+00:00"  
> although the local server time is one hour ahead. So the change of the
> logtime does not have no (direct) connection to the event problem.
> The logtime than warps to the current time:

Since this happens right after the first access to the Calendar API,  
it sounds like the user's timezone settings are different than that of  
the default PHP timezone. Kronoilth sets the default timezone, and  
this is probably affecting the logging output. It's only formatting  
though. The timestamps themselves don't change when the timezone  
setting is changed.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20140205/78f74c91/attachment.bin>


More information about the horde mailing list