On Tue, Jun 25, 2019 at 04:45:30PM -0700, Quanah Gibson-Mount wrote:
--On Saturday, June 22, 2019 2:06 PM -0700 Quanah Gibson-Mount
> [build@freebsd12 ~/git/openldap-2-4/tests/testrun]$ diff -u server1.out
> --- server1.out 2019-06-22 18:23:54.933600000 +0000
> +++ server3.out 2019-06-22 18:23:55.049209000 +0000
> @@ -1,3 +1,8 @@
> +dn: cn=Add-Mod-Del,dc=example,dc=com
> +cn: Add-Mod-Del
> +objectClass: organizationalRole
> +description: guinea pig
There appears to be two separate problems happening in test050.
Just seen another issue when the wait times are further reduced so as to
have the syncrepl establishment overlap with write traffic.
1. Servers start up and traffic starts coming in towards MMR node 1
2. syncrepl session from node 2 with node 1 as the producer is
3. Add/mod/del cycles run on node 1 and are replicated towards node 2
4. Node 1 starts to run a syncrepl session towards node 2 (somehow the
sid=001 cookie sent is older than the newest modification at the
time, but that wouldn't really change things)
5. That triggers a present phase and the add is propagated - this then
bypasses the sid source checks at the provider and csn checks on the
consumer and the entry is actually added
6. The next add/mod/del cycle starts before the deletion is processed so
add fails with LDAP_ALREADY_EXISTS and aborts the test.
It's probably the consumer CSN checks that need to be run again if we
don't receive the CSN with the PDU (which is what happens in present
phase), but that might have to be a '>=' on the contextCSN set rather
than a strict '>'? Something tells me that we need to deal with present
phase coming in with several entries with the same CSN.
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP