Re: detecting slow syncs
Lukas Zeller <luz@...
2010-02-02 11:23:20 GMT
On Jan 29, 2010, at 19:49 , Patrick Ohly wrote:
> Another peculiarity: on the server, after calling ABORTDATASTORE(),
> 'ReadSyncSet' is done and items are read from the database as part of
> 'GetItems'. On the client, only 'ReadSyncSet' is done. Server log below.
> Shouldn't the engine skip these steps because the store has already
Yes, it should but a check for isAborted() was missing after calling the <datastoreinitscript>. I have
added it now (bc0e54ca12 (Added check such that if <datastoreinitscript> calls ABORTDATASTORE(), the
abort gets propagated)), but I'm not sure it will improve the situation, as it will cause the entire sync to
stop, not just the datastore (because a problem in initializing the sync is considered a fatal error and
will lead to a AbortSession() (at syncagent.cpp:1171). On the other hand, I don't think just suppressing
operations on that single datastore would help a lot - most servers will expect a full sync cycle or then get confused.
We could check at syncagent.cpp:1171 if the abort reason status is zero (i.e. ABORTDATASTORE(0) called),
and if so behave differently, i.e. just muting that datastore, but leave the sessing running. But as said,
I'm not sure that will help with many servers.
> There is SLOWSYNC(), documented as "returns true if session is a slow
> sync". I found that it also returns true on a client if the session is a
> refresh-from-client. Is that intentional?
Yes. Within the engine, the term "slow" sync no only covers the two-way slow sync, but the "refresh" syncs as
well, as these are conceptually slows syncs as well. I think the SyncML standard docs used the term like
this at some point. So:
sync mode "Normal" variant "Slow" variant