Hello!
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
