---- Reported by jingke.zhang@intel.com 2010-04-19 19:41:11 +0000 ---- This is from http://bugzilla.moblin.org/show_bug.cgi?id=4282 Description From Chen Congwu 2009-07-10 02:45:28 PST (-) [reply] SyncEvolution now has client side suspend/resume capabilities, need to test does it work with different servers. ------- Comment #1 From Chen Congwu 2009-07-10 02:57:19 PST (-) [reply] ------- Test with synthesis server: Issues: 1) Cient::Sync::vcard30::Retry* for synthesis server. Most of the retry sessions are a resume(as excepted) except the last message from server was lost. Explain from Patrick: Yes, that's expected. I think I mentioned it on the list already, so I'll make it brief: the server thinks the session ended successfully, but the client knows otherwise because it didn't get that last message. This leads to an anchor mismatch and an unwanted slow sync. The standard requires that the server checks that the transport terminates the connection successfully after the last message, but that is hard to implement with a reply to a HTTP POST. 2) Need to adjust server-side timeout to a low value and changes is only committed after the session is aborted by server. Explain from Lucas: that's indeed a problem which is specific of TextDB (TextDB is not really suitable nor intended for productive use). Real DB backends commit when finishing processing a message so this problem does not occur there. ------- Comment #2 From Chen Congwu 2009-07-10 03:04:15 PST (-) [reply] ------- Test with Funambol: Funambol supports resume after a user suspend but could not resume after a abort. For interrupt tests, ClientRemove, ServerRemove will not pass, the cause is (take client remove as example): interrupted sync: client send out the delete cmd to server but failed to receive a response; thus server has deleted the item retry sync: this is a slow sync, the deleted item will be sent back to client, which means client has not deleted the item as expected. For suspend tests, Passed with a fix for libsynthesis. The issue is tracked here: http://www.synthesis.ch/indefero/index.php/p/libsynthesis/issues/7/ ------- Comment #3 From pohly 2009-07-10 04:13:27 PST (-) [reply] ------- Considering that many of the tests currently fail with our peer servers, should they be excluded from the nightly testing? I think so, because they also take a very long time to run. If we agree on that, then we should make registering the tests in SyncTests::addTests() conditional on environment variables: CLIENT_TEST_NO_INTERRUPT_RESUME CLIENT_TEST_NO_SUSPEND ------- Comment #4 From Chen Congwu 2009-07-12 05:50:36 PST (-) [reply] ------- Agreed. (In reply to comment #3) > Considering that many of the tests currently fail with our peer servers, should > they be excluded from the nightly testing? I think so, because they also take a > very long time to run. > > If we agree on that, then we should make registering the tests in > SyncTests::addTests() conditional on environment variables: > CLIENT_TEST_NO_INTERRUPT_RESUME > CLIENT_TEST_NO_SUSPEND ------- Comment #5 From Chen Congwu 2009-07-12 23:26:07 PST (-) [reply] ------- For text, ClientUpdate and ServerUpdate not pass either. I found a small issue in ClientTest(see congwu branch). After fixing it, the test still not passed, but looks more reasonable now: During slow sync, server could not identify the item is updated, instead it adds as a new item. (In reply to comment #2) > Test with Funambol: > > Funambol supports resume after a user suspend but could not resume after a > abort. > > For interrupt tests, > ClientRemove, ServerRemove will not pass, the cause is (take client remove as > example): > interrupted sync: client send out the delete cmd to server but failed to > receive a response; thus server has deleted the item > retry sync: this is a slow sync, the deleted item will be sent back to client, > which means client has not deleted the item as expected. > > For suspend tests, > Passed with a fix for libsynthesis. > > The issue is tracked here: > http://www.synthesis.ch/indefero/index.php/p/libsynthesis/issues/7/ ------- Comment #6 From pohly 2009-07-14 00:57:28 PST (-) [reply] ------- I've added a CLIENT_TEST_SKIP environment variable to client-test which (In reply to comment #3) > Considering that many of the tests currently fail with our peer servers, should > they be excluded from the nightly testing? I think so, because they also take a > very long time to run. > > If we agree on that, then we should make registering the tests in > SyncTests::addTests() conditional on environment variables: > CLIENT_TEST_NO_INTERRUPT_RESUME > CLIENT_TEST_NO_SUSPEND I've added a CLIENT_TEST_SKIP environment variable which can be used to list tests which are to be skipped. In contrast to CLIENT_TEST_FAILURES, the test (or test group) is not run at all. This solution is a bit more general than controlling the adding of individual tests. Code is in "master" branch, as required by the automated testing --- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC --- This bug was previously known as _bug_ 1000 at https://bugs.meego.com/show_bug.cgi?id=1000
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/6.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.