Hello Patrick, On 10.06.2013, at 11:57, Patrick Ohly <patrick.o...@intel.com> wrote:
>>> Looking at it like that, the question becomes: how does the server >>> decided that it still needs an answer from the client? >> >> Perhaps the problem is on the client side after all: in message msgID=2, >> the client client sent the Add command with a Final flag. In msgID=3, it >> acknowledges the server's SyncCmd with a Status, *without* a Final flag. >> The server therefore (in it's MessageEnded checks) continues with the >> session, whereas the client quits it. >> >> Should the client continue to set the Final flag as long as it is >> waiting for the server to finish? This is one of the things the specs did not nail and actual implementations varied. Some severely misbehaved when receiving extra <final/> (more than one per "phase"), and others were tolerant. Things are complicated further because <final/> is session scope, whereas the actual phase is datastore scope. This can lead to really strange overlaps when multiple datastores are involved. > It'd didn't do that because the server didn't set it either. > > My feeling is that untangling all these state changes is going to be > tricky. Undoubtedly. Untangling the code that hasn't become prettier over time would be one thing. However, the real problem is that there's no clear specs to even draw a state diagram in the first place. > I'll probably try something else: if commands were delayed in a > message which is marked Final, then force execution of the commands at > the end of processing that message and issue their Status commands, just > as syncing normally would. Sounds like a good compromise to me. > The effect will be that commands only get delayed across messages if > there will be more of them coming in anyway. The hope is that this will > avoid or at least minimize state change issues. > > Note that the problem that I am running into also exists in the > unmodified code: I expect similar issues when the server delays > processing because of timing. Probably not, because the server can only delay processing at the very beginning of the sync, while it loads the sync set in the background. So far, this was the only (but well tested with very long lasting sync set loads) case of delaying command execution. Delaying execution after sync has actually started is a new case. Best Regards, Lukas Zeller _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
