> On 08/12/2012 11:59 AM, Simo Sorce wrote:
> >> On 07/27/2012 12:15 PM, Petr Spacek wrote:
> >>> Hello,
> >>> this patch implements "Flush zones and RRs cache when handling
> >>> persistent
> >>> search reconnection" behaviour as requested
> >>> in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/44 .
> >>> Petr^2 Spacek
> >> Self-NACK :-)
> >> This second version has cache flush postponed a bit: Cache is
> >> flushed
> >> after
> >> receiving first result from LDAP. It should prevent unwanted cache
> >> flush in
> >> case of timeout or similar problems.
> >> Simo, are you ok with this approach?
> > Sounds better.
> > Ideally you do not flush until you get all results and no errors,
> > but if that's difficult, waiting until the first results come in
> > maybe be a decent first step.
> > Simo.
> AFAIK there is no SearchResultDone LDAP message, so it is a bit
See man ldap_result, the entries return with type LDAP_RES_SEARCH_ENTRY, the
last message is instead LDAP_RES_SEARCH_RESULT which tells you the searc is
This last message is never sent for a persistent search of course (IIRC :-).
But in case of a persistent search you should never need to flush as entries
are valid until you see a change.
> I created ticket for further improvements:
> Ideas from ticket:
> We can measure time between ldap_result() calls and say "done" if
> between two received results is greater than x seconds... but it is
> not very
> There is problem with high modification rates (10/sec as mentioned on
> freeipa-users list), because inter-result interval can be too long
> for those
> This "wait interval" can be shortened if result with Entry Change
> is received ... but it can lead to problem with result interleaving
> and so on.
> Further investigation is needed.
Freeipa-devel mailing list