On Mon, 2013-06-10 at 12:35 +0200, Lukas Zeller wrote:
> On 10.06.2013, at 11:57, Patrick Ohly <[email protected]> wrote:
> > 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.
It seems to be working, too :-)
> > 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.
Ah, I see. I had skipped over the
fLocalSyncDatastoreP->engIsStarted(false) check in the relevant code:
TSyncSession::processSyncOpItem()
...
// check if we can process it now
// Note: request time limit is active in server only.
if (!fLocalSyncDatastoreP->engIsStarted(false) || RemainingRequestTime()<0) {
aQueueForLater=true; // re-execute later...
return true; // ...but otherwise ok
}
--
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
