andreas(a)canonical.com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I also just uploaded a new attachment to the launchpad bug entry with the
> contents of the slapd.d/ directory.
Thanks, a fix was committed to HEAD yesterday.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I applied the diff from
http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/bconfig.c.diff?r1=1.…
to 2.4.20, rebuilt and retested, it works now.
Thanks!
- --
Andreas Hasenack
andreas(a)canonical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksWY94ACgkQeEJZs/PdwpCkoACg4xdTEzYb1QuQhjUfjtLHxSBK
74IAoMnwcVdaHsIhaiwwm8fnbx0DDgx8
=jss8
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I also just uploaded a new attachment to the launchpad bug entry with the
contents of the slapd.d/ directory.
- --
Andreas Hasenack
andreas(a)canonical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksVMTMACgkQeEJZs/PdwpAN5wCgru6E73Ex1kKdrSpwxCq6zbR9
vzcAmwczNIFgUK5w+8cz2gniT9g1NG8X
=IZTr
-----END PGP SIGNATURE-----
Michael Ströder wrote:
> Howard Chu wrote:
>> Howard Chu wrote:
>>> Michael Ströder wrote:
>>>> Howard Chu wrote:
>>>>> michael(a)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.…
>>>>
>>>
>>> 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=di…
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> michael(a)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.…
>
> 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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/