[os-libsynthesis] aborting a sync -> slow sync
Hello Lukas! Let me pick your brain for a second... :-) 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. 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. How is this case supposed to be handled? Is SyncEvolution doing something wrong in its change or meta data handling? My current workaround consists of detecting when the server side sends data to the client and resetting the admin data. If the sync does not complete, the next sync will be a slow sync because the server's sync anchor is gone. Is there a better way? -- 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
Re: [os-libsynthesis] aborting a sync -> slow sync
Hi Patrick, On 24.09.2014, at 17:33, Patrick Ohly 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). > 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? 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... > 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. Best Regards, Lukas signature.asc Description: Message signed with OpenPGP using GPGMail ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] aborting a sync -> slow sync
On Wed, 2014-09-24 at 21:14 +0200, Lukas Zeller wrote: > Hi Patrick, > > On 24.09.2014, at 17:33, Patrick Ohly 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 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] aborting a sync -> slow sync
On 25.09.2014, at 08:43, Patrick Ohly wrote:
> [...]
> Would this "save state" include resetting the sync anchor?
No.
> 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.
Even without suspend/resume, the client should remember unsent map commands and
send these at the beginning of the next session ("early maps") in all cases.
With these, the server will know of items actually added vs those only sent and
not added. AFAIK this "early map" even predates SyncML 1.2, but few
implementations actually used it.
> It's different on the client side because the client can detect the
> duplicate item based on the server's ID.
Yes.
>> 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 s inside, server aborts before receiving a response).
Ok, so it does not work as *intended* :-/
> So the expected result is that a suspend state needs to be written on
> both sides and then the next sync must resume?
With SyncML 1.2 and both sides capable (DB-wise) of Suspend&Resume, yes.
>> 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 the session normally.
>
> If STEPCMD_ABORT leads to suspend state being written and resuming the
> sync in the next session, why is STEPCMD_SUSPEND needed? My understanding
> is that STEPCMD_SUSPEND will take longer because it relies on further
> SyncML message exchanges. Does this perhaps make it more reliable?
STEPCMD_SUSPEND causes the client to send a suspend alert (explicit suspend),
whereas abort just saves the state and hopes for the other side to detect the
abort and save its state as well (implicit suspend). So STEPCMD_SUSPEND is the
more graceful way to stop a sync. In my mobile clients the stop button issues a
STEPCMD_SUSPEND when pressed the first time, and a STEPCMD_ABORT when pressed
the second time (e.g. for when network is stalled and the suspend message does
not get through).
Best Regards,
Lukas
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
