On 08/14/2012 08:25 PM, Simo Sorce wrote:
On 08/12/2012 11:59 AM, Simo Sorce wrote:
On 07/27/2012 12:15 PM, Petr Spacek wrote:

this patch implements "Flush zones and RRs cache when handling
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
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.


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 :-).

Right, it is what I tried to say with "there is no SearchResultDone LDAP 

section 4 paragraph b).

This patch deals with persistent search only. Non-persistent search scenarios have cache records with limited TTL value.

But in case of a persistent search you should never need to flush as entries 
are valid until you see a change.
Unfortunately, cache flush is necessary after persistent search reconnection. Records can change in meanwhile...

1. BIND started, cache was populated.
2. Persistent search connection was lost
3. Record was deleted (but Entry Change Notification wasn't delivered)
4. Persistent search connection was re-established - there is no information about deleted record/zone, BIND still sees old data in the cache.

For this reason https://fedorahosted.org/bind-dyndb-ldap/ticket/44 was filled.

What I missed?

Thanks for your time!

Petr^2 Spacek

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

Reply via email to