On Mo, 2011-09-12 at 09:56 +0200, Thomas Pequet wrote: > Le 24/08/2011 10:41, Patrick Ohly a écrit : > > The main problem is the fallback to a slow sync. Why does the server ask > > for one? > I think it is because there is no data in sync history: > https://www.memotoo.com/configuration.php?rub=infoSyncML > > Now if there is a "Last", Memotoo does not ask a slow sync.
I don't understand. This was not the first sync; I linked to the previous sync session in my email. Did you look at the examples and conclude that the server believes that the sync is the first one? > Try again and tell me. I've tried this repeatedly, it was reproducible. Unless you changed something, it is going to continue to fail. But I can try again. > > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.recv.client.B/syncevolution-log_trm001_002_incoming.xml > > > > The client sent 20110823T194959Z as its last anchor and sc-pim-B as its > > LocURI, which matches the values from the previous sync: > > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.refresh.client.B/syncevolution-log.html > > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.refresh.client.B/syncevolution-log_trm001_001_outgoing.xml > > > > Between these two syncs there was another one from the client sc-api-A: > > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.send.client.A/syncevolution-log.html > > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.send.client.A/syncevolution-log_trm001_001_outgoing.xml > > > > That also is an unexpected slow sync, but it doesn't show up as a > > failure because the end result happens to be as desired. Normally > > SyncEvolution's testing would check the sync mode and detect this, but > > for Memotoo that is disabled because we had these cases where it did > > unexpected slow syncs legitimately (no data on server). > > > > Is it possible that the server doesn't properly distinguish between > > multiple clients? > Normally Memotoo itendify the client with the "LocURI". > You can see if Memotoo does not identify the client and think it is > always "sc-pim-B" after "sc-api-A", with the RespURI and same sid (for > example: > <RespURI>http://sync.memotoo.com/syncML?sid=45e61e6e17edaefdbe6aaae70ce3fdb9</RespURI>) In other words, the sid is always the same for each client? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
