[Date Prev][Date Next]
Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
- From: firstname.lastname@example.org
- Date: Fri, 21 May 2010 17:35:04 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu:
>> Ralf Haferkamp wrote:
>>> A fix is now in syncprov.c r1.312. Would be great if someone could
>>> review it if it makes sense. Testing results look good so far.
>> Not sure why this makes the difference. After all, mincsn will be set
>> to the consumer's cookie, and any writes that occur during the
>> refresh phase will naturally have an entryCSN greater than mincsn and
>> still be queued.
> That doesn't seem to be true for deletes of entries that have an entryCSN
> less than the value from the cookie. What I did to reproduce the problem
> 1. load provider with about 100 entries
> 2. start consumer wait for it to get synced.
> 3. stop consumer
> 4. load more entries in to the provider (in my test case about 1000)
> 5. restart consumer (the consumer will start a ldapsync session with a
> 6. use ldapdelete to delete in an entry for the initial 100 entries.
> (those that have an entryCSN< csn provide in the cookie). This ldap
> delete as to happened during the refresh part of the ldapsync session
> (when the 1000 new entries are sent)
> 7. watch it fail
> What happens is that when syncprov_op_mod() calls syncprov_matchops() it
> tests the to be deleted entry against the syncrepl filter (which has the
> entryCSN>=cookie filter prepended currently as we are in refresh). That
> test fails because of the older entryCSN value. Because of that the
> syncoperation will not be inserted into the smatches queue of the
> opcookie and the delete will not get synched in the syncprov_op_response
> callback (as the smatches queue is empty).
> (As a side note: Modification that happen during the refresh phase will
> get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above
> reasons. This doesn't cause any failure AFAICS but seemed wrong as well.)
OK, that explanation makes sense. Just wanted to make sure we didn't regress
on ITS#4622, which seems to be the last time these filters were tweaked.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/