On Wed, 2014-09-24 at 21:14 +0200, Lukas Zeller wrote: > Hi Patrick, > > On 24.09.2014, at 17:33, Patrick Ohly <[email protected]> wrote: > > > Let me pick your brain for a second... :-) > > It has gotten a bit rusty as far as sync is concerned. But I'll try :-) > > > When SyncEvolution runs a local sync (i.e. both client and server are > > provided by SyncEvolution) and the sync gets aborted (= STEPCMD_ABORT is > > passed to SessionStep()), I noticed that the next sync starts again as > > if nothing happened. > > > > For example, aborting a normal two-way sync and then syncing again does > > another normal sync using the same sync anchors because the datastores's > > SaveAdminData has never been called during the aborted sync. > > What I *remember* (=not verified by looking at the code recently) is > that the engine tries to find out if "anything has happened" already > when the sync is aborted. > > If so, it would save state. Otherwise, it would just stop and next > sync would start "as if nothing happened" (because it thinks in fact > nothing of importance *has* happened, and avoid the relatively > expensive process of saving state).
Would this "save state" include resetting the sync anchor? I can't think of any other way how the server could avoid duplicates, because it cannot know whether the client has added the items and if so, under which ID... except that there is also suspend/resume. It's different on the client side because the client can detect the duplicate item based on the server's ID. > > The result is that the server can end up adding the same items twice, > > once during the aborted sync and again during the next one. This causes > > duplicates, because the client side has no means of detecting the > > duplicate. > > Did you actually see such problems happeing or do you just anticipate > them because they *would* occur if the engine *did* abort without > saving state in all cases? I've seen it happen in the the case that I described (message sent with several <Add>s inside, server aborts before receiving a response). > Now I could not resist looking at the code - two of these "early > abort" checks are in TSyncAgent::NextMessage(), look for "happened" in > the comments, but these only apply to early suspends, not abort. I > guess another relevant check is in > TLocalEngineDS::engAbortDataStoreSync(), look for "preventResuming". I > don't have the complete picture however from just this quick look > up... So the expected result is that a suspend state needs to be written on both sides and then the next sync must resume? > > How is this case supposed to be handled? Is SyncEvolution doing > > something wrong in its change or meta data handling? > > The only thing I could imagine going wrong would be not to continue > calling SessionStep() after the STEPCMD_ABORT until SessionStep() > actually signals session done, because it might take another step to > completely clean up the session, which is needed to make all > datastores call saveAdminData. I need to check this on both server and client side. I suspect that SyncEvolution is too aggressive on the client side and doesn't let it finish he session normally. If STEPCMD_ABORT leads to suspend state being written and resuming the sync in the next session, why is STEPCMD_RESUME needed? My understanding is that STEPCMD_RESUME will take longer because it relies on further SyncML message exchanges. Does this perhaps make it more reliable? -- 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 [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
