Tickets :: Comment on [#12506] Contacts sync with ActiveSync get duplicates and not sync

* Your Email Address
* Spam protection	Enter the letters below: .___. ..__ .__ .__ [__ \| \|[__)[__)[ __ [___\|__\|[__)[__)[_./
Comment	>> Well, from what you told me earlier, your device is not receiving >> any response from the server before it closes the connection. It >> doesn't matter what response we send if the client never sees it. > > Not exactly, the problem is the timeout (gap) between input from > device and output from horde. > > This is: > Device: Begin sending contacts > Device : Finish ADD contacts, waiting reply > GAP: Horde Begin adding contacts. > GAP: Horde Finish adding cotacts. > Horde: Begins sending replies (status). > ... > > If the GAP time is above 80 seconds (aprox.) Android timeouts and > close the connection before Horde begins sending replies. I have > tested other Android devices and this seems the behaviour in all > Android 4.1 versions. I need to test with 4.2 to see how this behave. > > The issue is that Horde "buffers" the replies and send them all at a > time later. I have always assumed this is right because you need the > status for the whole Sync and you can not know this until all > additions are processed. So I think in this process time the timeout > occurs because device does not receive any packet from Horde. > > If we reduce the process time, we reduce the "GAP" so this problem > does not arise. > > By examplle If I use the uploaded patch (hack) it only process the > first 50 ADDs in the packet, this sortens the GAP to less than 1 > minute and workarounds the timeout. With this patch (hack) Android > seems to work fine and sync all contacts with time. > >> What probably should happen is when a duplicate addition is detected >> we should return the existing item's UID as if the addition was >> successful. Of course, I have no idea what your client will do with >> this, since it is demonstrating broken behavior anyway, not to >> mention if the connection continues to timeout, this won't help your >> original problem anyway. > > This sounds really interesting, I would test it, I think it should > work, there are not additions so the GAP should be low. >
Attachment
Watch this ticket

Saved Queries