[Freeipa-devel] [PATCH 0042] Flush zones and RRs cache when handling persistent search reconnection

[Simo Sorce]

> 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
> problematic.

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 complete.

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:
> https://fedorahosted.org/bind-dyndb-ldap/ticket/86
> 
> Ideas from ticket:
> We can measure time between ldap_result() calls and say "done" if
> interval
> between two received results is greater than x seconds... but it is
> not very
> reliable.
> 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
> cases.
> This "wait interval" can be shortened if result with Entry Change
> Notification
> is received ... but it can lead to problem with result interleaving
> and so on.
> 
> Further investigation is needed.

Indeed.

Simo.