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

[Petr Spacek]

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

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

http://tools.ietf.org/html/draft-smith-psearch-ldap-01#page-3
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...

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