Pierangelo Masarati wrote:
This is probably an artifact of syncprov_qresp() which always allocates at least one byte for the queued CSN, thus the bv_val is never NULL. Which is why the test in compose_sync_cookie() was supposed to check BVISEMPTY, not BVISNULL.
I still strongly suspect that the BVISEMPTY test was just hiding a can of worms. I was running a sequence of add/delete on server 1; I'll call producer the server that receives the sequence of add/delete, and consumer the one that is replicated; however the trouble is caused when they act the opposite: it's syncprov on the consumer that sends bogus stuff to syncrepl on the producer. With yesterday's fixes, and after making sure each server was recognizing itself with the right SID (1 and 2), I caught the consumer sending back a bad cookie when playing the log. In any case, there appears to be an erratic behavior when performing deletes. What I infer from the logs is that the consumer sends back modifications to the producer with an incorrect cookie (sid=000), and either does not perform deletes, or does not perform them in time, and this causes trouble. I attach sanitized logs of both producer and consumer, in case they help, and I'll keep investigating.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------