Hello Congwu,
Thanks for analyzing that! That's apparently a bug in the server-case I
introduced with 6626a57e9e (Engine 3.4.0.5: implemented client-side
superdatastores according to suggestion/draft implementation of Patrick).
Your solution would work for server only, but break again some client cases.
The thing is - if engProcessSyncAlert() of the subdatastore returns a alertcmdP
(which it only does in server case), a non-zero status code is fully ok and
must not terminate the loop. On the other hand, when no alertcmdP is returned
AND the status is non-zero and non-508, this means a fatal problem occurred, so
there's no point in continuing the alert but the specific status code of that
problem must be reported back immediately.
I have pushed a fix in synthesis/luz: 80919e72e0 (Fixed server case of
superdatastore which was broken by 6626a57e9e (Engine 3.4.0.5: implemented
client-side superdatastores...))
Best Regards,
Lukas
On Mar 3, 2010, at 7:44 , Chen Congwu wrote:
> Since SAN does not have 'slow sync' option, SyncEvolution decided to implement
> this feature via 'force slow' in server side, eg:
> Client init sync with 'Alert 200', SyncEvolution rejects with status code
> '508'
> and a new Alert item 'Alert 201'.
>
> This caused a problem in superds implementation:
> in superdatastore.cpp:engProcessSyncAlert:
>
> for each sub datastore {
> call subds->engProcessSyncAlert;
>
> if (substatus.getStatusCode()!=0) {
> // basic problem with one of the subdatastores
> // - propagate error code
> aStatusCommand.setStatusCode(substatus.getStatusCode());
> // - no alert to send
> -----> return NULL;
> }
> }
>
> This means if any subdatastore returned a failed status code for
> engProcessSyncAlert, the superdatastore will return immediately without
> calling other subdatastores and itself. This caused the status for other
> datastores are still in idle state.
>
> A later 'sync' cmd with an 'alert' for a datastore in 'idle' state caused
> the engine return 'SYNC received too early". The client (Nokia 7210c) then
> continues sends its changes to server and the server this time has nothing
> to say but returns 'Alert 222', then the client also has nothing to say and
> responds 'Alert 222', this loops forever.
>
> Comment the returen statement, let the alert process proceeds which looks
> works
> for me. Do you have other suggestions for this?
>
> --
> Regards,
>
> Chen Congwu
> Moblin China Development
>
>
> _______________________________________________
> os-libsynthesis mailing list
> [email protected]
> http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
