[Date Prev][Date Next]
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
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 Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
(phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
"Howard Chu" <firstname.lastname@example.org>
Sent by: owner-openldap-devel@OpenLDAP.org
2003-10-20 09:55 PM
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
Symas: Premier OpenSource Development and Support