[Date Prev][Date Next]
You're right. Found the problem, it's working correctly again.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: Jonghyuk Choi [mailto:email@example.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
> 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
> 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: firstname.lastname@example.org
> (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
> "Howard Chu" <email@example.com>
> Sent by: owner-openldap-devel@OpenLDAP.org
> 2003-10-20 09:55 PM
> To: <openldap-devel@OpenLDAP.org>
> 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
> entry on every refresh interval. It seems to be finding
> everything with
> >= the last change. This should be CSN > the last change,
> yes? Otherwise
> consumer always repeatedly retrieves the last change made to
> a quiescent
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support