Bug 52764 - Suspend/Resume feature test for different servers
Summary: Suspend/Resume feature test for different servers
Status: RESOLVED MOVED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: SyncEvolution Community
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-19 19:41 UTC by SyncEvolution Community
Modified: 2018-10-13 12:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Patrick Ohly 2012-07-29 18:36:00 UTC


---- 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
Comment 1 GitLab Migration User 2018-10-13 12:38:16 UTC
-- 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.