3:26 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=3427
--- Comment #21 from Chen Congwu <congwu.chen(a)intel.com> 2009-08-28 08:26:44 ---
(In reply to comment #20)
(In reply to comment #19)
> Well, the testing have exposed a server side strange behavior
> (scheduleworld/funambol):
> Client::Sync::*::Resend::testResendClientAdd
> ------------------
> The normal message work flow
> out1: init sync
> in1: init sync
> out2: client changes
> in2: acknowledgment to client changes
> out3: Alert 222, continue
> in3: server side changes
> ...
> ------------------
In this scenario the server has seen message "out3", but its reply never
reaches the client, right?
> If out3 is resent, the server will never send server side changes but just
> acknowledges to the Alert222. The client has no way but continue send Alert
> 222, which will never end...
I bet the Funambol and ScheduleWorld server don't notice that the Alert222 is a
resend and therefore just send their standard reply instead of resending their
changes. Does it work if some of the earlier or later messages are resent?
Yes,
resend at message 1, message 2 and message 4 are all OK.
Can you bring this up on the Funambol *developer* list? Stefano Maffulli
encouraged us to use that list instead of the "general discussion" list. This
is probably worth mentioning before jumping into a description of the problem.
I
will follow up.
What can we do about this issue? Ideally the engine would detect that no
progress is made and abort, but I am not sure how easy that is.
I thought some
servers may use this behavior to keep the connection live.
I remember Lukas has mentioned this:
-------------
so again, servers will ensure that they can answer within 30 secs. Our
server has one operation that could take longer for huge datasets
(loading the sync set for a slow sync), and solves the problem by
sending "empty" responses (just non-<final/>, with Alert 222 when
needed) at least every 30 seconds (configurable, of course :-) while
the sync set loading is in progress.
-------------------------
If we cannot implement that, can we skip this problematic resend in
our
testing? Alternatively we have to disable the Resend tests completely for
Funambol and ScheduleWorld.
I am using CLIENT_TEST_INTERRUPT_AT=1 to workarount
this. The problem still is
there, if the network goes down and up just after sending out message #2.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4690
days inactive
4690
days old
syncevolution-issues@syncevolution.org
0 comments
1 participants
participants (1)
-
bugzillaļ¼ moblin.org