On 08/15/2012 05:18 AM, Simo Sorce wrote:
> ----- Original Message -----
>> On 08/14/2012 08:25 PM, Simo Sorce wrote:
>>> 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".
> I see.
>> 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?
> You missed nothing, I did.
> Howeve I have an idea to handle this situation smartly.
> We can issue 2 searches on 2 separate connections.
> The first search will be a persistent search, however it will be started with 
> a filter that has an additional element.
> Before the persistent search we do a rootdse search and find either the 
> higher modifyTimestamp or the higher entryUSN or equivalent, depending on 
> what is available in the server. Worst case we do a ase search of the DNS 
> tree and pick that modifyTimestamp.
> Then we start the persistent search with (&(entryUSN>%d)<normalfilter>) or 
> (&(modifyTimestamp>=%d<normalfilter>) (note modifyTimestamp requires >= due 
> to low resolution).
> On the other connection we start instead a nornmal search. This normal search 
> will terminate with a 'done' result, so you know that once that search is 
> finished you can flush any cache that has not been re-validated. While you 
> get any changes that are occurring live on the persistent search connection.
> This way we should be able to not loose any update and still know when we got 
> all results and drop unvalidated caches.

What is the status of this proposal?

> HTH,
> Simo.
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-devel mailing list

Reply via email to