On Fr, 2010-02-05 at 10:40 +0000, Lukas Zeller wrote: > On Feb 4, 2010, at 22:16 , Patrick Ohly wrote: > > > Now, for the server side things are bit more tricky. First of all, is > > there any way how the caller of the engine can determine the status of > > each source, as it can for a client via the progress events? The lack of > > progress events in the server is already a big problem for interactive > > monitoring of a running server session, but not getting information > > about per-source failures affects our error handling and reporting. > > Ok, I see that the progress events for the server must get more priority on > my todo list!
It doesn't necessarily have to be on your list, although I admit that I am a bit scared of having a go at it myself at this point because it'll touch quite a bit of code. > > Second, datastoreinitscript is apparently called when the server > > processes the "Sync" command. There is only one Sync command in that > > message, so the client-side trick of processing the whole message to > > determine the sync mode for all stores doesn't work. Hooking into the > > processing of the Status response of the client for the server's Alert > > won't work either, because someone client and server also only send > > Alert and Status for one store per message. > > > > When the client alerts the server, there are two Alerts in the message. > > Then the server replies with an Alert for only one of the stores. Why is > > that? Couldn't it include two Alerts in the same reply? > > Somehow I lost track now. In what situation do you see that happen? A normal sync with two datastores active. Synthesis as client and server. I'm attaching the log. > Basically however, the *message* is not a relevant unit, only the > *package* is. Implementations are free to split up any package into as > many messages as they like. For example I've seen implementations > which split the "updates from server" package into one message per > data item, probably to be able to detect data items that make the > client crash precisely. Understood. So the current implementation, which aborts the session in a client after the first *message* which contains server Alerts, is not guaranteed to work in all cases. As long as it works in most cases, I don't see that as such a big issue. The worst thing that can happen right now is that we detect an unwanted slow sync for one store and don't know anything about the others. > However, genereally thinking about the whole topic, I'm not sure if > trying to continue some syncs and aborting others is not asking for > potentially massive trouble with confused peers (222 loops etc.), > while gaining not much. Agreed. But we are not trying to continue the session. Currently, the client does a hard abort (no further messages sent) after detecting a slow sync in any store. The purpose of letting the engine continue with message processing is to detect the slow sync also for the other stores alerted in that message before stopping. > What is the cost of aborting the other datastores in case of an > unexpected slow sync? Say we have stores A, B, C. All of them would do an unexpected slow sync. If we detect this for A, but not B and C, then we can only report the problem for A. The user would have to solve this (e.g. refresh-from-server for A), then attempt a full with A, B, C. Repeat for B, then for C. It'll be less cumbersome if we can report and resolve the problem for A, B, C at once. Perhaps we should switch to only synchronizing one store at a time. I think Funambol does that now. The advantage is that if something goes wrong, like having to suspend, we know that only one store is affected. The disadvantage is slightly more network traffic and more logs - or perhaps not. Need to think about this. -- 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
