Michael Ströder wrote:
Howard Chu wrote:
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
michael@stroeder.com wrote:
Download content of testrun/ here:
http://www.stroeder.com/temp/openldap/its6405-test043-testrun.tar.gz
Shows that a change was replicated to the consumer and ignored on the consumer. But since there's no SYNC logging enabled, we don't see the reason why the consumer did this...
It does not happen very often. This time I had to run it almost 50 times.
Hope I got the sync log level right herein:
http://www.stroeder.com/temp/openldap/its6405-test043-testrun-sync-log.tar.b...
I think you have an OS / clock problem. The skipped op in this case got assigned an entryCSN older than the immediately preceding op. (The missing op has CSN 20091130201002.575384Z. The preceding op was 20091130201002.577244Z) This test doesn't run any concurrent operations, each new op is only submitted after the previous one completes, so this is not a thread concurrency issue, your system clock is going backwards.
A patch for this is now in libldap/util-int.c in HEAD.
Hmm, this is a virtual machine running in vmware-player 64 bit. But I didn't suspect to have a clock issue therein since the host is a rather fast dual-core notebook. I will investigate this.
The one thing you can rely on as far as clocks in VMware is that they will be wrong, regardless of your CPU speed.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...