Hello Thomas! Another ping... problem still exists in the nightly test runs.
Bye, Patrick On Mi, 2011-08-24 at 10:41 +0200, Patrick Ohly wrote: > On So, 2011-08-21 at 15:00 +0200, Thomas Pequet wrote: > > Le 19/08/2011 17:36, Patrick Ohly a écrit : > > > testDeleteAllRefresh: > > > 1. four items in sync on client and server > > > 2. client deletes all items, asks for refresh-from-client => no > > > items transferred > > > 3. slow sync to verify => four items recreated on client > > > > > > The server seems to have ignored the request to delete its data before > > > syncing in step 2. Is that intentional? > > OK now the four items will be deleted in server at 2. > > I have modified Memotoo. > > Confirmed, worked in the latests tests: > http://syncev.meego.com/latest/head-testing-amd64/nightly.html#memotoo > > However, something else broke. Now "testDelete" fails for all data > categories. For example, contacts: > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testDelete.log > > The problem is an unexpected slow sync, instead of the desired two-way > sync. This is the same problem as for testOneWayFromServer, see below. > > > > testOneWayFromServer: > > > 1. client A, B and server empty > > > 2. client A add one item, sends to server > > > 3. client B adds one item locally, does one-way-from-server > > I can not arrive to reproduce this test ... > > My SyncEvolution send Data "200" instead of "204" for "one-way-from-server" > > Sorry, I was looking at the wrong log (testOneWayFromClient instead of > testOneWayFromServer). > > > > The client asks for a 202 sync in its Alert > > > (http://syncev.meego.com/2011-08-19-07-20_testing_memotoo/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromClient.send.client.B/syncevolution-log_trm001_001_outgoing.xml). > > OK now Memotoo will return the anchor. > > Still fails. > > The latest test results for testOneWayFromServer are here: > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.log > > The one-way-from-server sync is this: > 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.html > > And here the message: > 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_001_outgoing.xml > > Note that the Synthesis engine asks for a normal, incremental sync. I > suspect that it does the one-way sync like that by simply not telling > the server about its own changes. > > The problem occurs when the sync has to fall back to a two-way slow > sync, because then items from the client do get sent to the server, in > contrast to the initial intention. IMHO this is a problem in the > Synthesis engine logic. But there's not much that can be done in that > case, except asking the users (as SyncEvolutions "prevent slow sync" > logic would do, if it was active). > > The main problem is the fallback to a slow sync. Why does the server ask > for one? > > 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? > _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
