On Fr, 2010-12-17 at 14:08 +0000, Lukas Zeller wrote: > On Dec 17, 2010, at 8:47 , Patrick Ohly wrote: > >> Now it turns out that there's a bad bug here, which probably explains > >> all this (and maybe other) weird behaviour. > > > > I'm glad that you got to the bottom of this. Much better than pampering > > over the symptoms. So my question now is: should the code that I added > > to detect collisions remain in the code? > > > > The loop which detects non-unique temporary IDs is harmless. But the one > > which iterates over all mappings to find a previous mapping to the same > > local ID has a real performance impact. > > > > My preference would be this: > > - turn the messages in these loops into real errors > > - keep them for a while > > - remove after the real fix has proven to be effective > > I fully agree with this, just go ahead!
Okay, working on it. I wondered why this bug did not surface in my "interrupted sync" tests. SyncEvolution's client-test simulates a whole range of different scenarios (items added/removed/modified) and a loss of network connection at any point in the sync session. I'm 100% certain that this passed when I declared SyncEvolution's server support ready for users. Looking at my test setup, I see that the server side was configured to use the file data stores. Those use very simple numbers as ID, and thus the whole temporary ID mapping code wasn't exercised. Rerunning the tests with the Evolution calendar store (which uses UID as local ID and thus depends on the mapping code) shows that the mapping problems *do* occur. My workarounds are triggered (visible in the logs), so the tests themselves finish successfully. With your patch applied, the are no longer triggered. IMHO this confirms that you found the root cause. An additional benefit is that the old meta data seems to be erased reliably. I don't think there's any further need for the "erase mapping on refresh-sync" feature that I was proposing. -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
