Re: syncrepl

[Jonghyuk Choi <jongchoi@us.ibm.com>]

I guess I didn't see this problem before the recent change was made. 

If you're referring to the lines 775~795 of back-bdb/search.c, I don't 
agree to your point.
The code segment modifes the filter in order to add (CSN > the last 
change) condition.
Because GT filter is not available,  &(!(CSN=the last change))(CSN>=the 
last change) is added.
(or we could save some by doing (!(CSN<=the last change)).

I suspect something broke cookie delivery from the provider to consumer.
Tracking of cookie values and the context CSN values in your experiment 
would help to identify the cause.

- Jong

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979    (fax) 914-945-4425   TL: 862-3979





"Howard Chu" <hyc@symas.com>
Sent by: owner-openldap-devel@OpenLDAP.org
2003-10-20 09:55 PM

 
        To:     <openldap-devel@OpenLDAP.org>
        cc: 
        Subject:        syncrepl



I think there's an incorrect condition somewhere in here. When running a
provider and consumer in the setup of test017, after adding the context
prefix to the provider and doing nothing else, I see the consumer obtain 
that
entry on every refresh interval. It seems to be finding everything with 
CSN
>= the last change. This should be CSN > the last change, yes? Otherwise 
the
consumer always repeatedly retrieves the last change made to a quiescent
provider.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support