Hello,
I just posted a fix for the client-side alert 222 loop detection,
using the idea Patrick suggested: 15a60aa254 (Alert 222 loop detector
improved: do not trigger as long as valid status is received) on
synthesis indefero, master, unilib, luz branches.
The counter is now reset whenever "essential" status (as indicated by
statusEssential() command method) is received. Non-essential status
answers are those for SyncHdr, (of course) Alert 222 itself, and a few
others.
Note that the statusEssential() function was already there and was
used in the decision to end a session for the server
(sessionMustContinue() used in ServerMessageEnded()).
The patch also makes Alert 222 generally non-essential - before it was
considered non-essential only in lenient mode. Of course it is
important for the loop detector that Alert 222 status is always not-
essential, otherwise it would reset the loop counter for every loop
and the detector would never trigger.
Patrick, can you verify the patch solves the delete case you ran into?
Best Regards,
Lukas Zeller
PS: As we have switched internally to using unilib and found no
regressions, I merged unilib into master (and luz) in the synthesis
indefero repository. As a point of reference: before that merge, the
master was at tag "libsynthesis_3.2.0.35".
All our own development will become available on master (and ongoing
work on personal branches like luz) as before.
On Oct 16, 2009, at 18:16 , Patrick Ohly wrote:
I'm afraid the 222 loop detection that Congwu added for the message
resend situation has negative side effects in other cases. Negative
like
"aborting a sync prematurely". I'm glad I found this before releasing
SyncEvolution 0.9.1 next week - now we just need a fix... ;-}
Here's what I ran into:
* get client and ScheduleWorld server into sync with several
hundred items
* delete all items on the client
* run two-way sync with a smallish message size (10KB)
* client aborts with "Warning: More than 5 consecutive Alert 222
within 20 seconds- looks like endless loop, abort session"
I'm not attaching the log, but can provide it on request. Instead I
extended client-test in SyncEvolution's master branch so that the
problem can be reproduced:
CLIENT_TEST_SERVER=scheduleworld \
CLIENT_TEST_NUM_ITEMS=1000 \
./client-test Client::Sync::vcard30::testManyDeletes
As far as I can tell, what happened is this:
* client sends a message to the server with a very compact list
of
deleted items
* server responds with several (> 5) messages that contain the
Status messages for the deletes
* soon the client has no changes left while the server is still
sending his Status replies, so the client starts sending Alert
222
Congwu, Lukas, you are both more familiar with this code than I am.
Could the loop detection be changed so that the counter is reset each
time genuine progress is made, like receiving status messages?
--
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.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
